CHOPLIFTER - Test inicial, pero no arranca [SOLUCIONADO]

[Marcos75]

Hola de nuevo.

Voy abriendo el hilo de la segunda Choplifter. Espero poder ponerme con ella esta tarde, o como muy tarde este fin de semana. De momento os cuento los síntomas que he visto. Todavía no la he inspeccionado en profundidad.

Esta placa hace un test inicial bastante largo, y mientras tanto aparece "IC TEST" en pantalla. Luego se van sucediendo cuadros de colores y demás, como si estuviese probando la memoria de video.

El primer síntoma es que la pantalla de IC TEST se ve, pero se ve mal, con los caracteres en posiciones distintas a como deberían aparecer. No sé si llega a completar el test o no, pero llega un momento en que el juego no sigue avanzando. No hay reseteo, pero el juego se queda congelado.

Esta tarde intentaré explicar más en detalle los síntomas, y os pediré consejo/ayuda.

Un saludo.

[Marcos75]

Bueno, pues ayer le dediqué más rato a la placa, y vengo con más información.

Esta placa no hace completo el IC CHECK inicial. Comparándolo con el de otra placa que funciona, se queda congelada antes. Además el problema de esta placa es que tiene fallos gráficos evidentes, con lo cual ni siquiera se leen las letras de IC CHECK.

Trasteando con la placa buena durante el IC CHECK, me doy cuenta de que en realidad va comprobando las memorias de forma secuencial. De forma que si "puteo" una memoria (por ejemplo juntando dos líneas de direcciones adyancentes), y da la casualidad de que el test está pasando justo por esa memoria, obtengo un error similar a BAD IC 39, por ejemplo. De esa forma, sabiendo más o menos en la placa mala dónde se para el test, trato de forzar el error en la placa buena en ese mismo instante, para determinar qué memoria está mal. Tengo que hacer esto porque aunque la placa mala me esté mostrando en pantalla el mensaje de BAD IC XX, no puedo leerlo debido a los errores gráficos.

Me centro solamente en IC39, IC2 e IC3, que son las memorias de video (el error es de video, está claro). En un primer intento parecía que es IC39, pero al cambiar dicha RAM el problema seguía. Luego me di cuenta que calculé mal, y la placa mala se congela JUSTO al terminar el test de IC39, y al empezar el siguiente. Con la placa buena determino que ese siguiente test es el de IC2 e IC3. Las he cambiado, y todo sigue igual.

Ahora me queda revisar por un lado los 2 x 74LS245 que hacen de buffer de datos para esa memoria, 1 x 74LS367 + 1 x 74LS244 que hacen de bus de direcciones, y el temido IC1, que es un CUSTOM, y que también interviene.

Tengo miedo de que haya algún problema con ese custom. Recuerdo en el pasado que tuve problemas con alguno de sus pines en una esquina (están retocados de soldadura). No sé si alguno estaba roto y lo reparé, o tenía un pegote de soldadura que unía varias patas, o similar.

Lo revisaré bien.

Continuará.

Un saludo.

[ArcadeHacker]

Buena tecnica. Se te ha ocurrido poner un analizador de logica en el addressing para ver el rango de direccion donde casca? (o a falta de un analizador led o varios)

[Marcos75]

Pues no tengo analizador lógico, y la solución de LEDs o el propio osciloscopio no me serviría, ya que todo sucede muy rápido, y necesitaría una herramienta que "deje traza o rastro".

Lo que sí hice es poner el osciloscopio en el /WE de las memorias y, cuando se produce el casque, apenas conté DOS pulsos, lo que quiere decir que el problema se produce justo al inicio del test. Es decir, hay alguna línea de direcciones que no se está generando bien, y / o alguna línea del bus de datos que no está bien.

En el primer caso (direcciones), hay dos posibles culpables:

- Los bufferes de direcciones que comenté antes (OJALÁ)
- El custom que controla el "tile map" (CHUNGO)

En el segundo (datos) de nuevo tenemos las dos posibilidades:

- Los bufferes de datos (245s) (OJALÁ)
- El temido custom IC1

De todas formas, estoy pensando sobre la marcha. Quizá me equivoque, pero este tipo de test de memoria entiendo que lo que hace es barrer la memoria secuencialmente, escribiendo un valor y leyéndolo a continuación, comprobando si el valor escrito y leído coincide. Y eso, por cada posición de memoria.

Si eso fuese así, un error en el bus de direcciones (líneas fijas, o flotantes) no se detectaría, ya que si el bus de datos está bien, se está escribiendo y leyendo lo mismo, aunque en una posición de memoria que no es la correcta. Quizá los tests son más complejos que todo eso...

Pero eso me hace pensar que quizá tenga que centrarme primero en los dos bufferes del bus de datos (los dos 245s...)

¿Qué opináis?

Un saludo.

[Pofo]

Puedes poner una foto de como ves esos caracteres defectuosos en el test?

[Marcos75]

Claro. Esta tarde cuando llegue a casa os pongo dos fotos. Una de la palabra IC CHECK en la placa buena, y otra con lo que se ve en la placa mala.

Un saludo.

[Characa]

Pero eso me hace pensar que quizá tenga que centrarme primero en los dos bufferes del bus de datos (los dos 245s...)

¿Qué opináis?

Un saludo.

Marcos, ante todo, enhorabuena por esas reparaciones; está claro que cuando uno se encuentra motivado, las cosas salen mejor.

Sin más rollos, lo que dices de los buffers tiene sentido, pues en una de las GALAXIANs que reparé, me pasaba algo similar, al hacer el test de memoria aparecía el texto mezclado con basura gráfica y el culpable era uno de los buffers de datos (fallaba una línea de dirección) y por ende el juego no se ejecutaba, se quedaba como haciendo un bucle.

Esperemos que se trate de eso y no del custom

Un saludo.

[ArcadeHacker]

Claro. Esta tarde cuando llegue a casa os pongo dos fotos. Una de la palabra IC CHECK en la placa buena, y otra con lo que se ve en la placa mala.

Un saludo.

Buenas Marcos, espero que esto te ayude:

Mirando el driver del System1 en mame (placa usada por Choplfiter) veo que el rango de memoria de video es la que he marcado en rojo, e000 a efff (4096 bytes).

/* main memory map */
  724  static ADDRESS_MAP_START( system1_map, AS_PROGRAM, 8, system1_state )
  725      AM_RANGE(0x0000, 0x7fff) AM_ROM
  726      AM_RANGE(0x8000, 0xbfff) AM_ROMBANK("bank1")
  727      AM_RANGE(0xc000, 0xcfff) AM_RAM AM_SHARE("ram")
  728      AM_RANGE(0xd000, 0xd7ff) AM_RAM AM_SHARE("spriteram")
  729      AM_RANGE(0xd800, 0xdfff) AM_RAM_WRITE(system1_paletteram_w) AM_SHARE("paletteram")
  730      AM_RANGE(0xe000, 0xefff) AM_READWRITE(system1_videoram_r, system1_videoram_w)
  731      AM_RANGE(0xf000, 0xf3ff) AM_READWRITE(system1_mixer_collision_r, system1_mixer_collision_w)
  732      AM_RANGE(0xf400, 0xf7ff) AM_WRITE(system1_mixer_collision_reset_w)
  733      AM_RANGE(0xf800, 0xfbff) AM_READWRITE(system1_sprite_collision_r, system1_sprite_collision_w)
  734      AM_RANGE(0xfc00, 0xffff) AM_WRITE(system1_sprite_collision_reset_w)
  735  ADDRESS_MAP_END


Mirando el codigo de las Roms de Choplifter veo que la palabra IC CHECK se encuentra en la dirección: 0x963E (esta zona es banqueada a trozos de 16k) y que la escritura en memoria de video para sacar la palabra por pantalla se hace en 0xE310.

Comentas que ves la palabra pero con los caracteres en lugares incorrectos, esto me da a pensar que el problema no está en la zona de dirección de memoria de donde se obtiene el texto (963E) sino en la de video (E310), de lo contrario dificil que vieras las letras que forman la palabra.

Te dejo las direcciones en bits:

        15                            0
963E: 1001 0110 0011 1110
E310: 1110 0011 0001 0000

[Pofo]

Perdona edcross, es que no entiendo bien, de que vale tener esas direcciones? Es que estoy espeso y no caigo.

Segundo, como viste que la salida de sacar por pantalla es  esa direccion? Y de que vale eso?

Gracias. Y perdona es que esto para mi es algo nuevo, yo nunca he reparado con estos datos.

Lo dicho, perdon Por mi poca pericia.

[ArcadeHacker]

Pofo, esto tiene multiples utilidades para afinar el problema, por ejemplo, que chips o bits de direccionamiento se encuentra el fallo, o hasta clavar con mas exactitud el problema una vez podamos ver la pantalla que le sale a Marcos.

El texto IC CHECK sale en pantalla por lo tanto la cpu llega a la zona de memoria de la rom donde se encuentran esos bytes que forman la palabra, pero no es capaz de sacarlo por la pantalla bien, signo de que potencialmente tiene problemas en enviárselo a la memoria de video (el video recogerlo de esta).

De aquí podríamos pasar a multiples escenarios, por ejemplo, si vemos que el texto sale a trozos en partes diferentes de la pantalla, y miramos como funciona el programa que ejecuta esa impresión, se puede llegar a deducir con mas exactitud el tipo de problema.

Aqui el programa:



Mis comentarios del código traducidos a un lenguaje más practico:

El programa mete al byte actual al que apunta el registro DE (dire de mem video) lo que tiene el byte al que apunta el registro HL (comienza con el primer caracter de la palabra IC CHECK)
Incrementa DE (dir mem vid), incrementa HL (siguiente carácter), y decrementa BC (el contador de cuantas veces se va a repetir el ciclo)
Carga el contenido del registro A ( el numero 8 ) en el byte al que apunta DE (dir mem vid). Supongo que el numero 8 es el color de la paleta con el que imprimir el caracter.
Incrementa DE (dir mem vid)
Vuelve a comenzar si la parte B (byte alto) del registro BC no es 0. El bucle se hace 8 veces hasta completar la palabra ?IC CHECK?, intercalando siempre el numero 8 entre cada letra.

Nota: El lector entendido apreciará que en este caso esta cpu no está escribiendo los pixeles a la pantalla directamente, alguien en otro sitio lo hace, por ejemplo: esa dirección de mem de video es una matriz de pantalla que sabe leer los caracteres con su color de paleta correspondiente y pasarlos a pixeles...

Perdona edcross, es que no entiendo bien, de que vale tener esas direcciones? Es que estoy espeso y no caigo.

Segundo, como viste que la salida de sacar por pantalla es  esa direccion? Y de que vale eso?

Gracias. Y perdona es que esto para mi es algo nuevo, yo nunca he reparado con estos datos.

Lo dicho, perdon Por mi poca pericia.

[Marcos75]

Hola a todos. Voy por partes:

1) Las fotos que comentamos. En la primera podéis ver lo que veo en pantalla en la placa mala. En la segunda lo que veo en pantalla flexando la placa mala (ahora hablaremos de eso). En la tercera, lo que debería ver.

   

2) He reparado dos malos contactos que provoqué yo mismo ayer al quitar las memorias 6264 y poner zócalos.

3) Flexando la placa en la zona "afectada", la imagen de basura cambia a mejor. Esta placa está muy combada por esa zona, lo que me hace pensar que alguna soldadura no esté bien. Tendré que repasar bien toda la zona antes de seguir.

4) Antes de eso, he cambiado los bufferes de datos, sin éxito (los 245s). El problema que tengo con esta zona es que está totalmente inactiva (bufferes inactivos, memorias con /WE desactivado, etc.) hasta que le llega el test, momento en el cual el programa se congela. NO PUEDO VER NADA. Y eso me llevó a acordarme precisamente de ti, edcross

Antes de nada, y respondiendo a tu post, muchas gracias por el trabajo. Está claro que el fallo está en la memoria de video. Tengo muy claro la arquitectura de esta parte (el generador de los "tiles"), pero tengo el problema que comentaba antes, no veo nada porque justo cuando esta parte "entra en acción", el programa se bloquea (CPU en HALT).

Se me había ocurrido desensamblar el código, anular la rutina IC CHECK, y grabar un código parcheado que me permita trastear en la placa. Sinceramente, mi ensamblador de Z80 está un poco olvidado. Quizá tú, edcross, me pudieses echar una mano con este tema. Por supuesto, solamente si te apetece.

Si fuese así dímelo, y te doy algún detalle adicional que te pudiera servir. Si no, quizá lo intente yo más adelante. Por ahora no voy a ponerme a cambiar más intengrados al tun-tún, porque realmente no veo nada raro en la zona en la que estoy mirando.

Eso sí, revisaré bien el tema de posibles soldaduras que se hayan "aflojado".

Muchas gracias de nuevo.

Un saludo.

[Marcos75]

Edcross, acabo de leer tu mensaje, nos hemos cruzado.

Efectivamente, la CPU no escribe píxeles en pantalla. El circuito que dibuja en pantalla en las placas arcade sigue un patrón muy concreto. Se puede implementar de varias maneras, pero la filosofía es siempre la misma. Pintar cuadraditos de 8 x 8 píxeles, barriendo toda la pantalla.

Un saludo.

[Pofo]

Marcos tal vez debieras mirar el apartado de video pero fijate lo que te digo, no veo yo que el problema lo tengas en la ram de video, mas bien diria que tu problema esta en la logica de video que gestiona estos datos, no se si un custom o como lo hara tu placa.

La logica dice que mires los buses de la tam de video, buffers y tal pero yo por lo que he visto en mis placas me decanto por logica de video que maneje esa ram.

Saludos y como yo de desemblador y eso no tengo ni flowers me quedare leyendo ajjajajajaj, a ver que se me queda.

[ricky2001]

A mi me habéis dejado flipado  siempre he sabido que se poco, pero ahora ya si que lo tengo aún mas claro jajajajajaja

Impresionante mirarlo desde ese lado, yo también intentaré aprender lo que pueda de esta reparación

Saludos

[ArcadeHacker]

Gracias, no tenía ni idea, todavía no entiendo muy bien como va la parte del video las arcade, veo tanto chip y tanta rom y me rasco la cabeza preguntandome "Y todo este lio para que??" jaja

Me parece muy buena idea lo de parchear la rom para saltar el ic check inicial. No creo que sea muy complicado, lo miro ahora y te posteo una solución.

Edcross, acabo de leer tu mensaje, nos hemos cruzado.

Efectivamente, la CPU no escribe píxeles en pantalla. El circuito que dibuja en pantalla en las placas arcade sigue un patrón muy concreto. Se puede implementar de varias maneras, pero la filosofía es siempre la misma. Pintar cuadraditos de 8 x 8 píxeles, barriendo toda la pantalla.

Un saludo.

[Pofo]

Joder edcross, eres un crack colega.

Voy a ver si me documento de ensamblador de z80, esto esta pillando un level de la pradera que creo que me voy a quedar de mero lector jajaa...

Yo siempre he analizado las placas desde el prisma logico, nunca desde el soft. Creo que mi metodologia esta obsoleta.

Me dedicare a leeros jijijiji

[Marcos75]

Pofo, en realidad muy pocas reparaciones se pueden solventar desde el lado del software pero, como en este caso, revisando el software podemos conseguir algo de "ventaja".

Edcross, muchas gracias. Las ROMs de programa que necesito son las de la versión unprotected:

Código: [Seleccionar]

epr-7152.ic90 32768 fe49d83e 307be38dd73ed37b275c1b464d266a752cb06132 good chopliftu
epr-7153.ic91 32768 48697666 0f4c6db9558272f5ceb347e742b284474f18b707 good chopliftu
epr-7154.ic92 32768 56d6222a ad8ccf15fe7f1d6716f78490892da0167d79f678 good chopliftu
La rutina de IC CHECK tiene que estar muy al principio, y debe realizar multitud de bucles de lectura escritura. Quizá incluso sea una subrutina de interrupción. Además, como pista, esa rutina antes de empezar tiene que ir a la memoria a leer algo, y en función de ese algo se ejecuta o no. Lo digo porque si reseteas la placa a mano, o apagas y enciendes rápido, el IC CHECK no se ejecuta.

Espero que estas pistas te faciliten algo.

Muchas gracias de nuevo.

Un saludo.

[ArcadeHacker]

Aqui tienes, con parchear la rom ic90 ha sido suficiente, ya no hace verificaciones. Curiosamente toda la rutina cansina del principio está en otro sitio, ic92, se carga banqueada al inicio en 8000-bfff desde la segunda mitad de la rom (16ks).

https://www.wetransfer.com/downloads/541794985ce2b2437deb011893f534d620140508213635/c83a47626cf3238eecaf930937ece3c020140508213635/845fd5

Ya contarás que tal, suerte!

Pofo, en realidad muy pocas reparaciones se pueden solventar desde el lado del software pero, como en este caso, revisando el software podemos conseguir algo de "ventaja".

Edcross, muchas gracias. Las ROMs de programa que necesito son las de la versión unprotected:

Código: [Seleccionar]

epr-7152.ic90 32768 fe49d83e 307be38dd73ed37b275c1b464d266a752cb06132 good chopliftu
epr-7153.ic91 32768 48697666 0f4c6db9558272f5ceb347e742b284474f18b707 good chopliftu
epr-7154.ic92 32768 56d6222a ad8ccf15fe7f1d6716f78490892da0167d79f678 good chopliftu
La rutina de IC CHECK tiene que estar muy al principio, y debe realizar multitud de bucles de lectura escritura. Quizá incluso sea una subrutina de interrupción. Además, como pista, esa rutina antes de empezar tiene que ir a la memoria a leer algo, y en función de ese algo se ejecuta o no. Lo digo porque si reseteas la placa a mano, o apagas y enciendes rápido, el IC CHECK no se ejecuta.

Espero que estas pistas te faciliten algo.

Muchas gracias de nuevo.

Un saludo.

[ArcadeHacker]

Gracias, lo mismo digo yo cuando os veo surfeando de integrado a integrado como si fuese mantequilla 

Joder edcross, eres un crack colega.

Voy a ver si me documento de ensamblador de z80, esto esta pillando un level de la pradera que creo que me voy a quedar de mero lector jajaa...

Yo siempre he analizado las placas desde el prisma logico, nunca desde el soft. Creo que mi metodologia esta obsoleta.

Me dedicare a leeros jijijiji

[Marcos75]

Muchas gracias, edcross. Mañana grabo una nueva EPROM y pruebo. Así será mucho más fácil localizar el fallo.

¿Nos puedes contar brevemente cómo se llamaba a la rutina? ¿Desde el programa principal con un salto directamente? En ese caso, ¿has puesto NOPs donde estaba el salto a la subrutina?

Lo dicho, gracias de nuevo. Mañana os cuento.

Un saludo.

[Marcos75]

Me contesto a mi mismo. Ya veo que has modificado el sato, para que en vez de ser a #8000 sea a #9400 (supongo que ahí empezará el código principal).

Antes de acostarme voy a probar en MAME.

EDITO: En MAME funciona de puta madre. Lo de probarlo es porque algunos juegos realizan alguna comprobación tipo checksum, y no arrancan si se modifica o se parche la ROM. Por ejemplo, cuando desencripté el Wonder Boy III no funcionaba porque tenía una rutina que comprobaba ciertas posiciones de memoria. Como yo había modificado dichas posiciones (las había desencriptado), la rutina entraba en bucle infinito.

Mañana grabo la EPROM,  y a seguir con la reparación. Muchísimas gracias de nuevo, edcross.

EDITO 2: Por cierto, si no tenéis un buen desensamblador a mano, podéis usar este online. No tiene mala pinta:

http://onlinedisassembler.com/odaweb/

Un saludo.

[ArcadeHacker]

Correcto, pero al reves. de 9400 a 8000. Muy bueno esto del Odaweb.

Me contesto a mi mismo. Ya veo que has modificado el sato, para que en vez de ser a #8000 sea a #9400 (supongo que ahí empezará el código principal).

Antes de acostarme voy a probar en MAME.

EDITO: En MAME funciona de puta madre. Lo de probarlo es porque algunos juegos realizan alguna comprobación tipo checksum, y no arrancan si se modifica o se parche la ROM. Por ejemplo, cuando desencripté el Wonder Boy III no funcionaba porque tenía una rutina que comprobaba ciertas posiciones de memoria. Como yo había modificado dichas posiciones (las había desencriptado), la rutina entraba en bucle infinito.

Mañana grabo la EPROM,  y a seguir con la reparación. Muchísimas gracias de nuevo, edcross.

EDITO 2: Por cierto, si no tenéis un buen desensamblador a mano, podéis usar este online. No tiene mala pinta:

http://onlinedisassembler.com/odaweb/

Un saludo.

[Marcos75]

Correcto, pero al reves. de 9400 a 8000. Muy bueno esto del Odaweb.

Ups. Claro, así no me cuadraba a mi que hubiese dos saltos seguidos a 8000 en la ROM original. Ahora sí me cuadra, sabiendo que es en la ROM "parcheada"

Un saludo.

[Rockman]

Me despisto un dia y ya teneis montado un taller de assembler!!!! :-)

Genial edcross que aportes tus conocimientos en ensamblador aplicados a la reparación. Mi enhorabuena.

Yo se un poco de cada cosa y a la vez no se nada! Siempre hay cosas que aprender... y poco tiempo.
Ya me miraré con calma el hilo.

Pero ya como recomendación y viendo hacia donde va esto, hay una herramienta super potente para trazar lo que estais haciendo usando el debugger de Mame. Podeis seguir paso a paso el funcionamiento del juego teniendo la ventana de la imagen del juego por un lado y en otra el flujo del programa con todos los registros y memoria. Os puede servir mucho sobre todo a ti edcross que tienes el ensamblador bastante más fresco que los demás.

Saludos.

PD: viendo tan solo el pantallazo de Marcos con carácteres y basura, parece como que no coje del lugar correcto lo que tiene que pintar en pantalla y no lo muestra en el lugar donde debería. (Creo que acabo de escribir una obviedad jajjaja) Aquí es donde el Fluke de edcross sería de gran utilidad para saber donde tenemos a la CPU.

[Pofo]

Oye rockman, yo el ensamblador lo tengo muy fresco, tengo el libro delante del ventilador.

Aqui edcross nos ha dejado a todos con el culo vuelto jijijijijiji. A mi esto me paece chino, pilla este registro, lo llevas a tal posiciom, una instruccion que pilla tal otra....otra que es para la cpu...

Yo ya no tengo la cabeza pa esto, pero si edcross hace algun codigo generico para que las placas con watchdog funcionen (que manden datos y se salte el reseteo) en placas z80 y 68k....alucinaria pepinillos y seria de mucha ayuda. Ya se que me vais a decir que el reseteo viene de otro lado no de la cpu y que las lineas estan comprometidas por la propia averia....pero por preguntaaar...lo mismo se me escapa algo.

Saludos.

[Marcos75]

Rockman, yo ya he usado el debugger de MAME tal cual dices. Cuando desencripté el Wonder Boy III, había como os comenté antes una rutina que comprobaba unas direcciones de memoria, y entraba en bucle infinito (al haberlas yo modificado). Gracias al debugger y a la ejecución paso a paso la localicé y la anulé.

Y aquí el Fluke no nos servirá de ayuda. El problema es que los circuitos que aquí intervienen están desactivados mientras no llega su test. Y justo cuando empieza su test, que podríamos empezar a ver señales coherentes, la CPU entra en HALT, con lo que no ves nada de nada. Para poder reparar esta placa con lógica, y no cambiando chips al tun-tún, solamente queda la opción de parchear el código, desde mi punto de vista.

Pofo, el watchdog es hardware puro y duro. No se puede parchear ningún código para anularlo, porque no es código. El watchdog controla la CPU, y no al revés.

Un saludo.

[ArcadeHacker]

Dos apuntes y una pregunta:

1- Yo si creo que el fluke puede ser de utilidad aquí, esos componentes que indicas Marcos pueden ser activados desde el mismo fluke, o por ejemplo tambien cargar roms banqueadas. Pero hay que saber como llamar a cada cosa claro...

2- Con el fluke puedes pasarte el watchdog por el forro (ignorarlo), pero ojo, dependiendo de cada placa, otros componentes que sigan al watchdog no vas a poder controlarlos.

Me interesa mucho ese debugger del Mame, donde lo veo o activo?

[enricnes]

Ed, bajate la version debug. Suele estar para descargar junto a las otras en la pagina oficial.

Con el fluke creo recordar que puedes trazar el programa, poner breakpoints y no me extrañaria que pudieras modificar una instruccion "al vuelo"

[ArcadeHacker]

Oye rockman, yo el ensamblador lo tengo muy fresco, tengo el libro delante del ventilador.

Aqui edcross nos ha dejado a todos con el culo vuelto jijijijijiji. A mi esto me paece chino, pilla este registro, lo llevas a tal posiciom, una instruccion que pilla tal otra....otra que es para la cpu...

Jaja, placas a la lavadora, manuales ventilados...vamos bien!

Te animo a que te pongas con el libro que puse en el hilo del Bubble, y que con paciencia vayas paso a paso. El mundo del asm es retorcido de cojones pero una vez que vas entendiendo las cosas es gratificante sentarse y entender el codigo.

Uno de los motivos de de pq admiro tanto los arcades es por el hecho de la unión increible de 3 cosas muy complicadas de conseguir: 1- Un juego bueno/jugable/epico 2- Un codigo en ensamblador hecho a mano 3- Un hardware diseñado a medida para todo lo anterior. Todo esto por equipos bastante reducidos en comparación con la cantidad de batallones de gente que participa en la creación de juegos actuales.

Me parece y me seguirá pareciendo increible.

[Marcos75]

1- Yo si creo que el fluke puede ser de utilidad aquí, esos componentes que indicas Marcos pueden ser activados desde el mismo fluke, o por ejemplo tambien cargar roms banqueadas. Pero hay que saber como llamar a cada cosa claro...

Hola edcross. Quizá esté subestimando al Fluke, pero no veo cómo hacerlo. Ten en cuenta que aquí entran en juego varios integrados de distinto tipo. Os cuento brevemente, a ver cómo podríamos hacerlo:

- Existe una memoria RAM que contiene punteros a las ROMs, donde se almacenan los tiles.
- Esa RAM se direcciona de dos maneras. O bien con las líneas xH y xV de barrido (durante una pintada normal en pantalla), o bien con las líneas de direcciones de la CPU (en el ciclo en el que la CPU carga la información de punteros en la RAM, durante la retraza). Es decir, ahí tenemos multiplexores, y bufferes, más la RAM.
- Por otro lado, los datos de la RAM tienen también una doble vertiente. Por un lado se alimentan con los datos de la CPU, a través de bufferes (la CPU carga los punteros). Y por otro lado sirven para barrer las ROMs de las tiles (sacan direcciones para dichas ROMs, que son los punteros).

Además, el Choplifter gestiona las direcciones xH y xV con un custom.

El problema que yo tengo es el siguiente: los bufferes y el WE de la RAM se activa durante un instante inicial para escribir IC CHECK, y luego se desactiva. Los bufferes tienen sus salidas en alta impedancia, la memoria está en modo solo lectura. Y justo cuando empieza la actividad, la rutina IC CHECK provoca el HALT, que me deja todos los buses congelados.

¿Qué podría hacer yo aquí con el Fluke para retomar la actividad normal del bloque de pintado de los tiles?

2- Con el fluke puedes pasarte el watchdog por el forro (ignorarlo), pero ojo, dependiendo de cada placa, otros componentes que sigan al watchdog no vas a poder controlarlos.

¿Cómo puedes ignorar una señal hardware? ¿Nos podrías dar algo más de detalle al respecto?

Me interesa mucho ese debugger del Mame, donde lo veo o activo?

Aquí Rockman seguro que te puede ayudar más que yo. Creo que hay que compilar MAME de una manera concreta, pero no lo recuerdo. No me hagas caso.

Un saludo.

[ArcadeHacker]

Sin entrar en muchos detalles, varios ejemplos:

1- Con el fluke tu eres la CPU. Por lo tanto el parche que hicimos ayer para la rom ni lo necesitas. Puedes instruir al sistema que comience a ejecutar codigo desde donde tu quieras.

2- Con el fluke puedes generar patrones de datos, testeos de memoria, de rom, de IO, lineas del bus etc..etc...

3- Con el fluke puedes inyectar estados y patrones de estados en cualquier parte de la placa usando la sonda que lleva (Enricnes sabe de esto, el está haciendo una ya que no encuentra una barata original).

etc....

Resumiendo, hay que hacerse con uno. Que ademas queda muy bien en la mesa. 

1- Yo si creo que el fluke puede ser de utilidad aquí, esos componentes que indicas Marcos pueden ser activados desde el mismo fluke, o por ejemplo tambien cargar roms banqueadas. Pero hay que saber como llamar a cada cosa claro...

Hola edcross. Quizá esté subestimando al Fluke, pero no veo cómo hacerlo. Ten en cuenta que aquí entran en juego varios integrados de distinto tipo. Os cuento brevemente, a ver cómo podríamos hacerlo:

- Existe una memoria RAM que contiene punteros a las ROMs, donde se almacenan los tiles.
- Esa RAM se direcciona de dos maneras. O bien con las líneas xH y xV de barrido (durante una pintada normal en pantalla), o bien con las líneas de direcciones de la CPU (en el ciclo en el que la CPU carga la información de punteros en la RAM, durante la retraza). Es decir, ahí tenemos multiplexores, y bufferes, más la RAM.
- Por otro lado, los datos de la RAM tienen también una doble vertiente. Por un lado se alimentan con los datos de la CPU, a través de bufferes (la CPU carga los punteros). Y por otro lado sirven para barrer las ROMs de las tiles (sacan direcciones para dichas ROMs, que son los punteros).

Además, el Choplifter gestiona las direcciones xH y xV con un custom.

El problema que yo tengo es el siguiente: los bufferes y el WE de la RAM se activa durante un instante inicial para escribir IC CHECK, y luego se desactiva. Los bufferes tienen sus salidas en alta impedancia, la memoria está en modo solo lectura. Y justo cuando empieza la actividad, la rutina IC CHECK provoca el HALT, que me deja todos los buses congelados.

¿Qué podría hacer yo aquí con el Fluke para retomar la actividad normal del bloque de pintado de los tiles?

2- Con el fluke puedes pasarte el watchdog por el forro (ignorarlo), pero ojo, dependiendo de cada placa, otros componentes que sigan al watchdog no vas a poder controlarlos.

¿Cómo puedes ignorar una señal hardware? ¿Nos podrías dar algo más de detalle al respecto?

Me interesa mucho ese debugger del Mame, donde lo veo o activo?

Aquí Rockman seguro que te puede ayudar más que yo. Creo que hay que compilar MAME de una manera concreta, pero no lo recuerdo. No me hagas caso.

Un saludo.

[Marcos75]

Gracias edcross. Entiendo la teoría, pero no veo cómo llevarlo de manera sencilla a la práctica.

1- En el primer caso que indicas, entiendo que el fluke saca direcciones en vez de la CPU, y gestiona el bus de datos en lugar de la CPU. Y qué sucede con la CPU real, ¿hay que quitarla? Porque estará conectada al circuito, y generará sus propias señales en cuanto la alimentes. Me gustaría, si pudiera ser, que nos contases algo más de detalle en este punto.

2- En este segundo caso, entiendo que lo haces con la placa sin alimentar, y yendo integrado por integrado, ¿no? Porque si alimentas la placa ya no puedes tocar los buses, porque tienen su "vida propia". Si es como en el primer caso, puedes probar integrados individuales, pero no sistemas complejos, ¿no?

3- De nuevo, tengo dudas de lo que puede suceder si inyectas señales con la placa en funcionamiento, ya que estás forzando estados en unos integrados que "están vivos". Entiendo hacerlo con la placa apagada, de integrado en integrado, pero no me imagino a nivel práctico (la teoría sí la comprendo) cómo hacerlo...

Muchas gracias.

Un saludo.

[Andreas Naive]

Me interesa mucho ese debugger del Mame, donde lo veo o activo?

Simplemente lanza mame desde la línea de comandos con la opción "-debug".

[ricky2001]

Marcos en lo que contesta edcross te diré hasta donde yo se que la cpu se quita y conectas el fluke en su lugar, el hace de procesador y tu lo controlas todo, la placa entiendo que tiene que estar encendida si no sería imposible mandarla hacer cosas.

Espero tener uno de estos algun día

Saludos

[ArcadeHacker]

Gracias edcross. Entiendo la teoría, pero no veo cómo llevarlo de manera sencilla a la práctica.

1- En el primer caso que indicas, entiendo que el fluke saca direcciones en vez de la CPU, y gestiona el bus de datos en lugar de la CPU. Y qué sucede con la CPU real, ¿hay que quitarla? Porque estará conectada al circuito, y generará sus propias señales en cuanto la alimentes. Me gustaría, si pudiera ser, que nos contases algo más de detalle en este punto.

2- En este segundo caso, entiendo que lo haces con la placa sin alimentar, y yendo integrado por integrado, ¿no? Porque si alimentas la placa ya no puedes tocar los buses, porque tienen su "vida propia". Si es como en el primer caso, puedes probar integrados individuales, pero no sistemas complejos, ¿no?

3- De nuevo, tengo dudas de lo que puede suceder si inyectas señales con la placa en funcionamiento, ya que estás forzando estados en unos integrados que "están vivos". Entiendo hacerlo con la placa apagada, de integrado en integrado, pero no me imagino a nivel práctico (la teoría sí la comprendo) cómo hacerlo...

Muchas gracias.

Un saludo.

Creo que será mejor que haga un video-review de lo que se puede hacer con este trasto. Te respondo de forma simple:

-El fluke es una unidad de control y necesita dos elementos adicionales, un pod, y una sonda.
-El pod es basicamente una cpu real con una circuiteria que permite controlarla en todo momento.
-La sonda funciona de dos maneras, pasiva (sonda logica), activa (puede inyectar estados y patrones).
-El pod hay que enchufarlo reemplazando la cpu que hay en la placa, evidentemente si la cpu va soldada, entonces toca desoldar y zocalizar.
-Todo lo que se hace con el fluke es siempre con la placa encendida, primero se enciende el fluke y despues la placa o UUT (unit under test, argot del fluke)
-No pasa nada por inyectar estados desde la sonda a un integrado, evidentemente sabiendo lo que se hace. La inyección se limita a un punto a la vez, supongo que en el hermano mayor del Fluke 9010, el 9100, se pueden hacer mil cosas más, pero no idea.

Lo dicho, pensaré en un script para hacer un video review durante este mes.

[Marcos75]

Gracias por las respuestas.

Edcross, gracias, creo que ahora lo tengo claro. Ahora entiendo por qué dices que te puedes saltar el watchdog (al menos en la CPU principal).

Entonces, ¿el FLUKE sería capaz de leer el código de las ROMs y ejecutarlo? En ese caso, podría ejecutar el código ignorando el RESET del watchdog, ¿no es así?

Ricky, gracias, quitando la CPU me cuadra todo

Y gracias a Andreas por la aclaración sobre lanzar MAME en modo debug.

Un saludo a todos.

[ArcadeHacker]

Entonces, ¿el FLUKE sería capaz de leer el código de las ROMs y ejecutarlo? En ese caso, podría ejecutar el código ignorando el RESET del watchdog, ¿no es así?

Si, correcto pero ten en cuenta que otros componentes escuchan tambien al watchdog y esto puede limitar tu maniobrabilidad.

En mi caso con el Bubble llegado un punto tuve que acabar desactivando el watchdog para poder avanzar.

[Marcos75]

Entendido. Gracias por tus explicaciones.

Un saludo.

[Characa]

-El fluke es una unidad de control y necesita dos elementos adicionales, un pod, y una sonda.

El cacharrejo en cuestión, es capaz de simular todo uP viviente?? (8 y 16Bits)

Reparación de placas a nivel ensamblador; What level !!

Un saludo.

[enricnes]

Los pods basicamente son para cada CPU o familia. Creo recordar que habia hasta de 80286. Aunque los mas interesantes para nuestros menesteres son el Z80, el 68000 y alguno mas.
Saludos!

[Rockman]

Me interesa mucho ese debugger del Mame, donde lo veo o activo?

Simplemente lanza mame desde la línea de comandos con la opción "-debug".

Si no recuerdo mal hay que compilar o tener compilada una version de Mame (llano por linea de comandos) con las opciones de debug activas. El génerico no puedes activarlo.
En la pagina oficial de Mame teneis esta version con el debugger activado ya compilada para ahorraros compilarlo vosotros.
http://www.mamedev.org/release.html

Una vez lo tengais lo lanzais como dice Andreas tal cual como si fuerais a jugar a un juego pero con el -debug.
Por ejemplo:
MameXXX.exe pacman -debug

Os lanzara como dije la ventana del juego y la ventana del debugger donde podreis ejecutar paso a paso, observar la memoria y hacer todo tipo de perrerias al codigo del juego para analizarlo. Siempre teniendo la salida a pantalla del juego para saber en que punto tenemos la ejecucion del mismo. Una herramiento muy muy potente si esta en buenas manos.

A partir de aquí Haze nos podría hacer un cursillo acelerado a distancia. Jajajajaja (ojalá)

Saludos!

[Pofo]

Muchas gracias por la info edcross, lo de saltarse el wd es la caña, el cacharro ese es muy interesante, sera mi proximo juguete jijijijiji.

Es dificil de manejar? Nevesito tener idea de ensamblador? Explicanos un poco si no te importa.

Y gracias por abrir nuevas vias de analisis.


Oye, una pregunta, no se puede intervenir la señal del reset y usar un generador propio?, esto lo pregunto en general, es que me parece bastante factible.

[ArcadeHacker]

Es tan facil que hasta una cajera de supermercado puede usarlo. De hecho es lo que parece esteticamente, una caja registradora. Haré un video para demostrar todos los usos que tiene.

Muchas gracias por la info edcross, lo de saltarse el wd es la caña, el cacharro ese es muy interesante, sera mi proximo juguete jijijijiji.

Es dificil de manejar? Nevesito tener idea de ensamblador? Explicanos un poco si no te importa.

Y gracias por abrir nuevas vias de analisis.


Oye, una pregunta, no se puede intervenir la señal del reset y usar un generador propio?, esto lo pregunto en general, es que me parece bastante factible.

[Marcos75]

Por supuesto que puedes, Pofo, pero tienes que "modificar" la placa. En un caso genérico, tendrías que cortar una o dos pistas, para meter en medio tu propio generador de RESET.

Volviendo a la reparación, deciros que el parcheo de edcross ha funcionado perfectamente. Voy primero a revisar las soldaduras que os comentaba, y luego a meter osciloscopio a ver qué veo.

Así sí.

Un saludo.

[Andreas Naive]

Si no recuerdo mal hay que compilar o tener compilada una version de Mame (llano por linea de comandos) con las opciones de debug activas. El génerico no puedes activarlo.

Recuerdas bien, pero aún así creo que te equivocas.

En tiempos pasados era necesario tener compilada la versión de debug para poder depurar los juegos emulados. Sin embargo, eso era fuente de confusiones; en cualquier programa, lo habitual es que una compilación de debug sea la que te permite depurar el programa, en este caso el emulador.

Así que a qué depuración se refería la versión de debug; ¿a la del emulador? ¿a la del juego que el emulador ejecuta? Lo lógico, en mi opinión, para ser coherente con lo que es normal en cualquier proyecto de desarrollo, es que la versión DEBUG sea la que permite depurar el programa desarrollado, en este caso MAME (digamos, con GDB); en cambio, el depurador de los juegos forma parte de la funcionalidad soportada por el emulador, así que no tenía sentido hacerlo depender de la compilación de DEBUG. Por ello, hace un tiempo se decidió que todas las versiones tuviesen disponible el depurador:

http://mamedev.org/?p=231

No me suena que se haya revertido tal decisión, así que sospecho que con cualquier versión te vale; no obstante, no pongo la mano en el fuego, porque yo el que compilo en casa siempre es con la configuración de debug, claro.

[Pofo]

Es que veo bastante util esto de meter una señal de reset propia, es cosa de estudiar el esquema para ver donde se genera, levantar la pata y meter la nuestra. En la konami gt esto seria bueno para no hacer sangrar marcos.

Respecto al fluke 9010, me quedo esperando a ver que nos cuenta edcross

Ya nos cuentas que ves por la video rammarcos, ojala no sea el custom.

Saludos.

[Andreas Naive]

Pofo, al leer tu comentario sobre la intervención en la señal de RESET, he recordado la discusión sobre el Dallas de World Rally 2.

@edcross: pregunta: ¿el fluke acepta dos sondas lógicas? Lo digo porque el ataque de Kuhn contra el DS5002 requiere modificar la conexión del Dallas a la SRAM para inyectar código troyano, y se me ocurre que un cacharro con una sonda pasiva (para ver cuándo la SRAM responde) y otra activa (para enviar el código necesario al Dallas por la patilla levantada, bajo control de un uP) podría ser una manera de ensayar el ataque sin causar mucho estropicio en la placa.

[Marcos75]

¡Qué bueno! Os cuento:

Con el osciloscopio estaba revisando el buffer (74LS244) que pasa las direcciones de la CPU a las RAM que contienen los punteros de los tiles. Pues bien, estaba viendo que determinadas salidas no seguían aparentemente a sus entradas. En integrados tri-estado a veces pasa esto, no detectas los fallos bien porque las salidas pueden estar pulsando, porque lo que en realidad ves es la actividad del bus.

En fin, que me resultó extraño, y cuando lo desueldo, ESTÁ PARTIDO POR LA MITAD. Había visto esto en las EPROMs, que se les quita la "loncha" de arriba. Pero este integrado está partido por la mitad, literal. Se sujetaba únicamente por la parte metálica de dentro. Al estar soldado ni se notaba. Como os decía, esta placa está muy combada en esa zona. Quizá esa "doblez" haya sido lo suficientemente fuerte para partir el 244 (de hecho ha partido tres patas del CUSTOM, pero justo a ras de placa, con lo cual se han reparado muy fácilmente.

Bueno, el caso es que el segundo Choplifter está listo. Vamos a por el tercero.

Gracias edcross por el parcheo de la ROM. Me ha facilitado mucho la vida.

Un saludo.

[Characa]

Al final ha sido el buffer!!! ya ves, tanto assembler y ha resultado ser una "chuminada" 

Enhorabuena por este nuevo logro!

Un saludo.

[Rockman]

Enhorabuena Marcos por otra de tus geniales reparaciones.

Tambien tengo que dar la enhorabuena a edcross por mojarse en dar otro punto de vista a la reparación.


Por cierto tengo que dar la razón a Andreas. Efectivamente con la version "estándar" de Mame 0.153 se puede lanzar el debugger con la opcion "-debug".

Edcross te animo a que lo pruebes, tendrás más o menos un Fluke virtual conectado a Mame. (Aunque desconozco si puedes cambiar valores a la CPU a tu antojo como en la "caja registradora".

Un saludo al buffer "partio" también!

[ArcadeHacker]

Edcross te animo a que lo pruebes, tendrás más o menos un Fluke virtual conectado a Mame. (Aunque desconozco si puedes cambiar valores a la CPU a tu antojo como en la "caja registradora".

Un saludo al buffer "partio" también!

Ya lo he probado, está fantastico. Gracias!

[Rockman]

Retomo el hilo para hacer una "pequeña" consulta a edcross o quien domine más el funcionamiento del software de esta placa que yo. (fácil jajaja).

Intentando aprender el funcionamiento del debugger de Mame, he probado de localizar la posición de memoria donde esta el IC CHECK del test inicial de la placa. Sin desensamblar codigo, tirando directamente del debugger.

El texto que tengo que buscar es ("IC CHECK") en este caso está en el tercer archivo de la rom de cpu. La rom  "epr-7126.ic92" posición 0x563E.
Total que no entiendo como realmente luego hay que interpretar la posición 0x963E para el texto en cuestión en la memoria de la cpu, tal y como indicas.
Dijeramos que el espacio de memoria para el Z80 llega hasta 7FFF y luego jugando con alguna linea de direcciones supongo que debe hacer ese bank switching (no se muy bien como funciona) para el resto de la memoria de programa, pués amplia esa memoria con las otras dos roms, alternandolas según requiera la cpu.
Mirando tambien el driver de mame, si veis la disposicion de las roms van de 0-7ffff, 10000-18000 y de 18000-20000. (no van seguidas de una a otra, deja espacio entre medio).
luego mirando el mapa de memoria indica lo siguiente confirmando el banking:
 (...)
 AM_RANGE(0x0000, 0x7fff) AM_ROM
 AM_RANGE(0x8000, 0xbfff) AM_ROMBANK("bank1")
(...)
32Kbytes + 16Kbytes con banking (no se cuantos bancos afecta)
Sabeis como queda establecido ese banking y que bancos usa?

Resumiendo, pues eso como se hace para interpretar que la posicion 0x563E de la rom *.ic92 equivale a la 0x963E en la memoria del Z80???

[Marcos75]

Acabo de ver lo de 16K de banking. 16K son 3FFF, justo el offset entre la posición relativa 563e y la real 963e... ¿no? No sé realmente como funciona

Un saludo.

[Marcos75]

Ahí va mi hipótesis:

Este juego tiene 3 ROMs de 32K. La primera es la parte "fija", o sea, desde 0000 hasta 7fff. Las otras dos (también de 32K) contienen 2 bancos de 16K cada uno (4 bancos en total). En cada memoria, un banco comienza en 0000 y el otro en 4000. El banco donde está el IC CHECK es el segundo de una memoria, el que empieza en 4000. Por eso la posición que dices (563E) en realidad es la posición 163E de su banco, que puesta a continuación de la memoria fija, que llega hasta 7FFF, nos lleva a 963E.

Lo que no sé es cómo se controla todo eso a nivel software / hardware.

[Rockman]

Muchisimas gracias Marcos! eres un crack. Esa duda la tengo resueltisima.

Ya puestos a ver si conseguimos ver exactamente como realiza el "bank switching". Creo que se hace, gastando lineas de memoria a modo de interruptor, como si actuaran de chip enable.
Creo que gastara las dos lineas más altas de las dos memorias banqueadas. Segun active las cuatro posibles combinaciones, sabra cual esta leyendo de los cuatro bancos. De ahí que los bancos sean de 16K.

A ver si alguien nos acaba de explicar como funciona exactamente.

[Marcos75]

Hola Rockman.

En realidad son 4 bancos repartidos en 2 ROMs. Por eso se "gasta" únicamente A14 de cada ROM (la línea más alta) para seleccionar uno u otro banco.

En teoría, con memorias 27256 (de 32K) como tiene este juego, lo lógico sería que desde A0 hasta A14 sirvieran para direccionar directamente las EPROMs (2 elevado a 15 es 32K), y que A15 sirviera para seleccionar entre dos ROMs (32 + 32 = 64K).

En este caso hay TRES 27256. La "principal", que se direcciona como hemos dicho, y las dos que contienen los bancos. Y ahora el decodificador de direcciones no es tan simple como A15 a secas. Ahora se le mete A15, pero también A14, y de ahí se saca el valor de A14 para las dos EPROMs de bancos, y el valor de /OE para dichas EPROMs.

La duda que a mi me queda es cómo controla la CPU el codificador de direcciones, para seleccionar una u otra EPROM, y el banco superior o el inferior...

Un saludo.

[Rockman]

Pues más o menos lo que dije pero perfectamente explicado por ti Marcos!

En las roms banqueadas se usa una linea más (en total dos) para seleccionar los bancos de 16K.

El tema de la seleccion desde la CPU habría que mirarlo, pero o lo hace con "chips" (pals o lo que sea) o lo hace directamente por software adecuando las direcciones usadas para coger el dato que le interesa teniendo en cuenta el banking.

Gracias Marcos.

(A ver si saco tiempo y miro otra vez el debugger a ver si puedo localizar finalmente cuando llama a esa cadena de texto.)

[Marcos75]

En las roms banqueadas se usa una linea más (en total dos) para seleccionar los bancos de 16K.

Bueno, es que en realidad /OE no se considera una línea de memoria. En realidad solamente se utiliza una línea, A14, por eso puntualizaba tu mensaje.

Un saludo.

EDITO: A no ser que te refieras con "las dos líneas más altas de las ROMs banqueadas" a una línea por cada ROM. En ese caso estamos diciendo realmente lo mismo

EDITO: En este caso usa un multiplexor para generar las líneas de selección de ROM y banco. La selección es hardware pura, está claro. Pero las líneas de entrada de ese multiplexor, o al menos alguna de ellas, serán las que de alguna manera se puedan controlar por software. Al principio del código del Choplifter se realizan una serie de operaciones de entrada y salida que, quizá, tengan que ver con la selección de bancos. Aquí edcross nos podrá echar una mano

[ArcadeHacker]

Buenas Sres,

En este caso la System1 usa IO para seleccionar bancos, funciona enviando un byte a la dirección IO 0x15. En este byte se tienen en cuenta los bits 2 y 3.

Por ejemplo, enviando el byte 0C ( 0000 1100) cargaremos el ultimo banco de los cuatro:

ld a, 0Ch (cargamos 0x0C en registro A)
out (15h), a (enviamos el dato a la dirección IO 0x15)

Haciendo esto veremos que magicamente aparece cargado el banco en la dirección 0x8000.

Que hay detrás del IO 0x15? Según el driver de mame:

AM_RANGE(0x14, 0x17) AM_DEVREADWRITE("ppi8255", i8255_device, read, write)
Intel 8255  Programmable Peripheral Interface

[Marcos75]

AM_RANGE(0x14, 0x17) AM_DEVREADWRITE("ppi8255", i8255_device, read, write)
Intel 8255  Programmable Peripheral Interface

El 8255 es el que genera el resto de señales de control del decodificador de direcciones...

Gracias edcross por la explicación.

Un saludo.