STREET FIGHT - Sin sprites ni sonido [SOLUCIONADO]

[Marcos75]

Después de reparar la Empire City: 1931, me voy a poner con esta bootleg que tengo (son el mismo juego), que es prácticamente idéntica a la original, salvo por que sustituye el chip de seguridad por un aéreo.

Esta placa me fue muy útil para reparar la original, así que ahora espero que la original le devuelva el favor.

Los sprites no se ven. De vez en cuando aparece un destello en pantalla donde debiera aparecer el punto de mira, por ejemplo. Intercambiando placas con la original, he deducido que el problema está en la placa de arriba. La de abajo (video) parece estar mal también, porque muestra rayas en los sprites, pero eso lo miraré más adelante. Ahora hay que ver por qué no se ve nada de nada de sprites.

Además no suena. Cuando debe empezar una melodía se oye un "petardeo" (suenan dos o tres "golpes de altavoz"), y nada más.

Esta tarde me voy a poner con ella y os cuento más detalles.

Un saludo.

[Pofo]

Yo repare una y tenia un problema similar, pero no era en la cpu eran unas puertas logicas, no recuerdo de que tipo que pilotaban una señal que hiba a un dmpx creo recordar. No se si la tuya tendra que ver con eso o con la cpu porque en mi caso se veia la capa del fondo, no me queda clsro si tu caso es el mismo.

Tienes los esquemas de la original? Supongo que si.

[Marcos75]

No, no tengo los esquemáticos, pero estoy usando los de la Ghosts and Goblins, ya que en la parte de video son tremendamente parecidas ambas placas.

En este caso el problema no puede ser del doble buffer, porque el problema es en todo el sprite, y porque el doble buffer se genera en la placa de abajo. No se ve nada de nada de los sprites. Apostaría algo a que es el buffer de carga desde la CPU hasta la memoria de punteros de los sprites, o las señales que lo controlan (que se generarán en un demultiplexor, como tú dices).

En cuanto llegue esta tarde me pongo con ella.

[Pofo]

Si, podria ser que la señal del dmpx que controla esos buffers para enviar las punteros para que se cargen los graficos como dices...cuadra mucho...

De todos modos no descartaria que aunque parezca poco probable sea un tema de mezclas o incluso buffers en las memorias graficas, a mi es que me fallan mucho ultimamente pero es que tambien tiendo a agrupar tipos de averias.

A ver que tal...yo estoy con la xevious ahora mismo, odio estas tan ultratech...

[Marcos75]

Bueno, tengo lista la parte de sonido. Os cuento lo que he hecho.

El sonido tiene dos partes. Una controlada por un Z80, una ROM, su RAM y dos YM2203, y otra totalmente independiente con unos contadores, una EPROM y un M5205 de OKI. Lo primero es la melodía, lo segundo los sonidos digitalizados. Ambas partes estaban mal. La melodía no sonaba, y cuando tenía que sonar un sonido digitalizado, lo único que oigo son 3 ó 4 golpes secos.

El Z80 aquí se comporta de una forma curiosa. Está en modo interrupción la mayor parte del tiempo (inactivo), y con un pequeño pulso positivo estrecho periódico, sale del modo interrupción. En mi caso esto no pasaba, ya que el Z80 no sacaba la señal IORQ. El problema era que no estaba corriendo el código adecuado, porque la ROM de sonido estaba mal. De hecho al quitarla se ha partido un pin que estaba corroído. Al reemplazarla el sonido ha vuelto (las melodías).

La parte del OKI se gestiona con una EPROM que saca 8 bits de golpe, pero los pasa por un 157 (multiplexor), que le entrega al OKI primero 4 bits, y luego otros 4 (el OKI funciona con 4 bits. Pues bien, cuando debe sonar un sonido digitalizado, las entradas de los 4 multiplexores del 157 se mueven, pero las salidas permanecen a nivel bajo. Al cambiar el 157 los sonidos digitalizados han vuelto.

Ahora, a por los sprites.

Un saludo.

[Pofo]

Ala...a por la cpu...

[ricky2001]

Marcos que fácil parece leyéndote, enhorabuena, creo la avería de los sprites estará temblando ya porque sabe que la pillas en seguida.

Saludos

[ArcadeHacker]

Un ninja, que facil das con todo!

[Marcos75]

Qué va. Le dedico muchas horas al tema, lo que pasa es que contándolo parece que he ido a tiro hecho. Pero la mayoría de las ocasiones me doy muchos tortazos antes de dar con las averías. Por ejemplo, por hoy ya basta. No doy con el problema de los sprites.

Gracias por vuestros comentarios.

Un saludo.

[Rockman]

Eres un crack Marcos! No me puedo creer luego que se te atragante una simple eliptica! ;-)

Creo y espero que dispones de los esquematicos, porque si no me quito el sombrero por el nivel de detalle de funcionamiento que averiguas solo analizando la placa...

[Pofo]

Rockman....son muchos años...si esto fuera una carrera, marcos estaria en octavo curso ajajajjaajjajaajaj

[Marcos75]

Jejeje, sois la pera, chavales. No tengo esquemáticos. La parte de video era muy similar al Ghosts and Goblins, y por eso fui más rápido. La parte de buffer de datos de esta es una putada, con muchos bufferes contribuyendo, y sin esquemáticos. A ver si mañana más fresco doy con ello. No me gustaría empezar a cambiar integrados al tuntún.

Rockman, la elíptica fijo que con vuestra ayuda también cae...

[Marcos75]

Bueno, voy a ponerme otra vez con ella. Ayer estuve casi toda la tarde siguiendo una "pista falsa", creo. Tengo la corazonada de que los sprites sí se están "generando" bien, pero no se están "pintando" bien. En la placa superior está el mezclador de colores, y creo que el fallo pudiera estar ahí. Me estaba obcecando en que era en la generación, pero ahí solamente interviene el bus de datos y de direcciones, y si hubiese algún problema en esos buses muchas cosas se verían afectadas, no solo los sprites.

La buena noticia es que el mezclador de colores es bastante similar al del Ghosts and Goblins, así que vuelta a los esquemáticos

[Marcos75]

La de abajo (video) parece estar mal también, porque muestra rayas en los sprites

De momento he resuelto esto, y la placa de video esta bien. Una de las dos RAMs del doble buffer tenia una pista rota. Lo he detectado con el osciloscopio porque la señal en su pin D3 no seguía el mismo patrón que las otras. El caso es que la rotura es minúscula (no se ve casi ni al trasluz), y está en un sitio protegido, con lo que me decanto a un fallo de fabricación. La placa seguramente funcionaba, pero con el tiempo la pista "se ha ido". Al repararla los sprites, con la placa de CPU buena, se ven de maravilla.

Pero estoy estancado. Mi teoría de esta mañana no parece buena, porque los sprites aparentemente se están pintando bien. Así que vuelvo a la generación de los mismos. Lo que me parece increíble es que la generación es casi toda en la placa de video, que en combinación con la de CPU buena funciona bien, con lo cual el problema lo tengo en la placa CPU pero no sé qué mirar.

Esta placa es muy curiosa, porque en el bus de datos hay muchos momentos en alta impedancia. En otras placas también los habría, pero suele haber un puente de resistencia que ata las señales a nivel alto cuando no hay actividad en el bus. En la original que funciona 100% es así. En la bootleg que estoy arreglando también, pero alguien puso en su día (quizá en fábrica) un puente de resistencias soldado por detrás de un componente, para tratar de atar las señales. Es un puente de solo 470 ohm (demasiado bajo para mi gusto). Mi idea es quitarlo. Lo desconcertante es que está en la placa de video, que ya os digo que parece funcionar. Aún así creo que lo voy a quitar a ver qué pasa.

Un saludo.

[Marcos75]

Bueno, pues sigo con los avances, acotando el tema, pero sin solucionarlo.

Descartado que el error fuese al "pintar" los sprites, está claro que es cuando se "generan". Estaba dando por hecho que el problema está en el bus de datos, al otro lado de la CPU, pero parece que viene de antes, de la zona de la CPU.

He comparado señales en el buffer que mete en el bus de datos los datos de la CPU, entre la placa buena y la mala. He tenido que ir cambiando la escala de tiempos hasta que he visto diferencias claras. A la mala le falta una "ráfaga" de datos que sí tiene la buena. Pero montando en la mala un 245 encima, y dejando una pata levantada, para ver qué mete en el bus, me doy cuenta que el 245 no está mal, con lo que la falta de datos viene del otro lado, del lado de la CPU.

De momento tengo dos sospechosos: las señales de control de ese 245 (ENABLE y DIR), y un 374 que también mete datos en este bus, y no sé para que sirve, porque casi todas sus entradas están fijas tanto en la placa buena como en la mala.

De momento el tema parece acotado. Ahora a comparar señales entre las dos placas.

Un saludo.

[Marcos75]

Acotado mis cojones. Es un poquitín endiablada esta placa del lado de la CPU (del buffer de datos p'adentro). Resulta que tiene dos EPROM de programa, pero la segunda la puedes quitar, que el juego arranca, ya que solamente guarda información gráfica. Pues bien, no hay continuidad entre sus respectivos 8 pines de datos. Solamente entre 4. Los otros 4 de cada una de ellas van a una PAL. Y para colmo está el 374 del que os hablé, que mete directamente datos a la CPU durante la interrupción.

Vamos, que hay que estar fresco para afrontar esto, y yo tengo ya la pelota como un bombo.

Un saludo.

[Marcos75]

Bueno, pues lo tengo. Una de las reparaciones más elaboradas y difíciles a las que me he enfrentado. Y de la que más he aprendido, sin duda.

Por cierto, edcross, Rockman, y cualquier experto en Z80, leed hasta el final, que luego os quiero hacer una pregunta

La cuestión está en que tenía el problema ya acotado a este lado del bus de datos, es decir, en la zona de CPU. Además, con la placa que funcionaba, montando un 245 encima del que da paso al bus de datos y levantándole una pata, veía lo que se metía desde la zona de CPU al bus de datos. Ahí descubrí que la placa buena metía una ráfaga de datos, que no metía la mala.

Bueno, pues después de volverme loco con la protección de este juego, con una PAL de por medio, y después de mirar muchísimas señales, me di cuenta de que la ráfaga de datos que buscaba se metía en el bus durante unos 130 useg, así que usé la señal del 245 con la pata levantada como trigger en el osciloscopio, viendo en el otro canal qué pasaba en otras partes.

Después de hacer muchas suposiciones, y comprobar el sentido de los datos, y un montón de señales de control, me di cuenta de que en el bus de direcciones, durante ese pequeño instante, hay direcciones incoherentes (señales fijas, alta impedancia, etc.). ¿Cómo cojones puede ser que el Z80 esté generando señales buenas siempre, menos en esos 130 useg...? Pues bien, parece que en ese periodo no es el Z80 quien genera las señales, sino que vienen de alguna otra parte. En la mayoría de las placas que conozco el bus de datos es unidireccional, pero en este caso es bidireccional, y durante esos 130 useg vienen las direcciones impuestas de fuera, y leen la memoria, sacando los datos. Pues resulta que uno de los 245 que hacen de bus de direcciones funciona de puta madre en el sentido normal, pero parece fallar en el sentido contrario. Casi imposible verlo, si no estás buscando el error (imaginaros lo que son 130 useg...).

Lo he cambiado, y los sprites han vuelto.

Y ahora viene mi pregunta. Yo pensé que tanto en los ciclos de lectura como de escritura, el Z80 era quien ponía las direcciones. En este caso, el ciclo este extraño es de lectura, pero no es el Z80 el que pone las direcciones en la memoria, sino un elemento externo. ¿Existe algún modo específico del Z80 que se comporte de esta manera? O es simplemente un truco hardware / software capaz de poner sus líneas de direcciones en alta impedancia?

Muchas gracias.

Un saludo.

[Pofo]

En otro tipo de placas que uso yo,  ambos buses son usados en rafagas cortas para otra logica periferica a la cpu, nun se si es como tu caso, en concreto para hacer operaciones sobre ram y luego la cpu lo usa.

[ricky2001]

Anda que si tengo yo que encontrar eso....
Enhorabuena, a ver si te aclaran eso que es muy interesante.

Saludos

[Marcos75]

Anda que si tengo yo que encontrar eso....

Pues probablemente lo hubieras encontrado mucho antes que yo.

En mi caso es que me tomo esto como un hobby, y me gusta mucho aprender, y saber el por qué de las cosas. Hace un par de años empezaba a desoldar integrados hasta dar con el culpable. Ahora intento estar muy seguro de qué está fallando, y por qué.

Un saludo.

[Pofo]

Anda que si tengo yo que encontrar eso....

Pues probablemente lo hubieras encontrado mucho antes que yo.

En mi caso es que me tomo esto como un hobby, y me gusta mucho aprender, y saber el por qué de las cosas. Hace un par de años empezaba a desoldar integrados hasta dar con el culpable. Ahora intento estar muy seguro de qué está fallando, y por qué.

Un saludo.

Hombre, dejarte llevar de un palpito en un integrado si, pero no creo que fueras desoldando asi porque si nunca :p

Yo lo que he ido anotando secularmente es mis reparaciones en una libreta de estas tipo cuartilla (hace poco empece la tercera libreta) y he ido haciendo una estadistica de componentes que me fallan...sabeis que es lo que mas fallos acumula? Os va a sorprender (quizas) no son cuarzos ni inversores ni buffers.....las RAMS (en concreto 6116 y equivalentes), por lo demas no me ha servido de nada la estadistica porque es casi proporcional a su presencia.

Eso si, ciertas placas tienen averias recurrentes, sobre todo boots como la tumblepop y un contador que hace aparecer lineas.

Lo que si que creo que emoezamos todos era descartando lo bruto....osea, pulso alto, pulso bajo...oscila....tabla de verdad al lado....

[Marcos75]

Por cierto, se me olvidó comentar que aunque le he puesto lo de SOLUCIONADO al hilo, es porque me dejé llevar por la emoción del momento.

En realidad noté que hay algún pequeño inconveniente con el scroll horizontal de los sprites. Cuando el punto de mira está en reposo no hay problema, pero al desplazarlo en horizontal se ven algunas motas blancas a la misma altura, pero en posiciones distintas.

En este caso lo primero será asegurarme de que es problema de la placa de video (estoy casi seguro, pero lo confirmaré intercambiando placas con la original que tengo que funciona 100%). Luego tiraré de los esquemáticos del Ghosts and Goblins En este caso sospecho de los sumadores 283, como ya me pasó con la placa original.

Si puedo esta tarde, me pongo y os cuento. Lo siguiente van a ser tres Star Force de Tecfri que tengo aparcadas. Aunque tengo ya en la colección una Star Force traída de Japón (de las de tres pisos), me gustaría incorporar esta versión posterior de dos pisos. Juegazo donde los haya.

Un saludo.

[Pofo]

Muy interesantes esas star force de tecfri...no sera una de pegatinas redondas no? Porque si es asi te mando otra foto al correo esta tarde jajajajajaj

[ArcadeHacker]

Marcos, si he entendido bien, dices que otra cpu o componente mete direccionamiento en el mismo bus usado por la cpu?

Pero quien acaba consumiendo los datos pedidos por el direccionamiento?

[Marcos75]

Hola edcross. Trato de explicártelo:

Durante ese periodo del que hablo, el direccionamiento parece venir de un contador, es decir, se hace un barrido secuencial de direcciones. Las direcciones son para la RAM principal de programa, porque en ese ciclo las dos EPROM están deseleccionadas, y la CPU está en un ciclo de lectura, y dicha RAM está también en un ciclo de lectura.

La RAM enchufa los datos directamente al bus de datos a través del buffer de datos. Es decir, la CPU no recoge esos datos. Irán probablemente directamente a la RAM intermedia que guarda los "punteros" de los sprites. El proceso parece ser el siguiente: la CPU ha almacenado en la RAM en algún momento anterior la información de sprites, pero luego quien se encarga de "extraer" dicha información no es la propia CPU, sino un contador externo en combinación con el buffer del bus de datos.

El inconveniente que yo le veo a esto es únicamente que la CPU durante ese periodo tiene sus direcciones "forzadas" por un elemento externo. Es decir, es un ciclo en el que a la CPU no le importa los datos que haya a su entrada, ya que ni los lee ni los trata. La pregunta es: ¿tiene que estar la CPU en HALT para hacer eso? ¿Existe otro estado, provocado por una instrucción de software, o incluso por una combinación de señales de control, que permitan a la CPU ponerse en ese estado? ¿La señal WAIT, cuyo funcionamiento desconozco, puede participar en esto?

Muchas gracias.

Un saludo.

[ArcadeHacker]

A nivel fisico de ser entre Halt o Wait, sin duda Wait. Wait es una entrada mientras que Halt es una salida.

Cuando llevas /Wait abajo la cpu deja de ejecutar y por lo tanto seguro que no va a usar el bus.

Otra opción con halt es que a nivel de código la cpu vaya ejecutando halts y anunciandolo mediante el pin de Halt. La cpu saldrá de halt cuando haya recibido una interrupción.

[Marcos75]

Gracias por la explicación. Lo de HALT también me parecía un poco "fuerte", pero el comportamiento es suficientemente raro como para que no fuese descabellado...

Como tengo que pinchar de nuevo esta placa con el osciloscopio, probaré lo del WAIT. Lo que me resulta curioso es que es normal que a un Z80 le lleguen WAITs, lo que no sé si cuando le llegan pone su bus de direcciones a nivel alto o no (en este caso debería ser así, para no afectar las direcciones que se están poniendo en ese momento en el bus).

Siguiendo tu pista lo miraré esta tarde.

Un saludo, y gracias de nuevo.

[Marcos75]

Mirad lo que acabo de leer:

There is also a pin named /BUSREQ that can be used to request access to these buses. The Z80 will periodically check this pin and if it is held low it will put the data, address and control buses into a high-impedance state and drive /BUSACK low to acknowledge this. This effectively removes the Z80 from the circuit, and another device can now drive the buses.

Creo recordar haber visto siempre, o casi siempre, /BUSREQ a nivel alto. No sabía que existía esta opción en la cual el Z80 se "quita de en medio". Quizá esto, combinado con un WAIT, es lo que está pasando. Lo comprobaré esta tarde.

[ArcadeHacker]

En ese caso fijate tb en BUSACK, es el flag que usa la cpu para indicar que ha soltado el bus, quizas el circuito se active mediante eso?

[Rockman]

Muchas gracias Marcos por pensar que soy un experto en Z80, jajajajja ya me gustaría poder responder a esa pregunta. Creo que debes conocer tu más que yo el Z80. Yo vamos, más bien poquito.

A ver si entre todos podemos resolver el misterio o por lo menos saber por donde van los tiros. Molaría tener los planos de la placa para ver un poco de lo que estamos hablando.

Puede ser que sea el microcontrolador que lleva la placa para la proteccion del juego que anule la CPU principal durante un lapso de tiempo?
Cada cuando ocurre ese fenomeno Marcos? es ciclico, ocurre al iniciar la placa?

(PD: un dia me tienes que explicar como coj**** sacas tanta información usando tan solo el osciloscopio de dos canales. Es una currada mirar uno por uno los pines para ver cosas...)

(PD2: En referencia mi anterior "PD", Marcos, luego me cuentas como sincronizas y ves el bus de direcciones, la señal de control /BUSREQ para ver como le llega la peticion del "sujeto" externo y luego como activa la linea /BUSACK el Z80 y la gestion del bus de datos......solo con 2 CANALES!!! grrgr)

[Marcos75]

Lo miraré, pero creo que van por ahí los tiros. El problema que yo veía es que para que el invento funcione, el Z80 debe "levantar las piernas" para que "barran por debajo", sino estorbaría. Pero con esa información, todo pinta bien.

Rockman, cuando entiendes cómo funciona una placa de forma general, luego es más fácil hacer este tipo de intuiciones. Os puse más de una vez un enlace a un documento increíble, de cómo funciona el sistema MCR2. Pues bien, las demás placas, en mayor o menor medida, funcionan de manera similar.

Aquí lo que pasa es lo siguiente: la CPU principal debe enviar la información gráfica a las RAMs correspondientes en cada refresco de pantalla, para que se pinte a continuación. Por un lado background, por otro lado sprites, y por otro lado el resto de capas que hubiera. En la mayoría de las placas que he tenido oportunidad de analizar, todo el trabajo ese de la CPU lo hace ella solita. En este caso, la información de sprites la pasa de forma particular:

1º) La CPU guarda la información en un lugar de la RAM (este proceso no lo he visto, pero me lo imagino)

2º) Periódicamente, la CPU cede el bus de direcciones a un contador externo (sospecho que al propio contador horizontal), que hace un barrido de la RAM principal, y enchufa los datos de sprites directamente al bus de datos, de donde los recoge la RAM que guarda el estado de los sprites en pantalla (los punteros hemos comentado alguna vez).

3º) La CPU retoma el control

Un saludo.

[Marcos75]

(PD2: En referencia mi anterior "PD", Marcos, luego me cuentas como sincronizas y ves el bus de direcciones, la señal de control /BUSREQ para ver como le llega la peticion del "sujeto" externo y luego como activa la linea /BUSACK el Z80 y la gestion del bus de datos......solo con 2 CANALES!!! grrgr)

Rockman, en realidad es casi como si tuvieses 1 canal, ya que necesitas utilizar el otro prácticamente para que haga de "trigger". Me explico: muchas veces necesitas ver cosas que suceden en instantes determinados, pero con un grado de detalle muy amplio. Es decir, tienes que poner la base de tiempos con pocos useg, con lo cual no ves casi nada si no centras la imagen justo donde necesitas. Y para ello juegas con el otro canal como "trigger".

Entonces tienes que poner un canal en una señal de control adecuada para lo que quieres ver, y luego ir con el otro canal sondeando señales.

Por ejemplo, para detectar cuándo se actualiza la información de los sprites, tuve que irme al bus de datos, poner un 245 encima, levantar una de las patas (para ver únicamente la información que se mete en el bus, y no la que está ya en el bus, que me genera ruido), y poner ahí la sonda del canal 1 (la que tiene el trigger). Ajustando la base de tiempos, consigues que la imagen que ves en el osciloscopio comience justo cuando se inyecta al bus de datos la información que buscas. Luego con la otra sonda ya vas viendo cómodamente señales.

A veces ves saltos, porque el trigger se lanza en otro sitio, pero la mayoría del tiempo ves una imagen más o menos estable en pantalla.

Un saludo.

EDITO: Esta tarde si tengo tiempo hago unas capturas de pantalla. Voy a necesitar ayuda, porque me va a faltar una mano

[Rockman]

Gracias por la explicación Marcos, y entiendo perfectamente como consigues aislarlas para verlas, pero es una autentica currada como filtras las señales que quieres ver con el osciloscopio.
Usando un analizador lógico y asignando una secuencia de trigger (o trigger que se activa en combinación de varias señales) puedes ver eso y a la vez con varias de las señales, para tranquilamente luego analizar lo que ha ocurrido.

Lo que me falta a mi es entender más el proceso de funcionamiento de las placas para seguirte mejor. Estas placas hacen florituras para que con un procesador "pequeño", hacer cosas grandes. Pero bueno en este tiempo he aprendido un poquito.

Esta claro que aprovechas bien tus equipo. ;-)

[Marcos75]

Bueno, pues con la ayuda de mi princesita de 5 años dándole al IMPRIMIR PANTALLA del portátil, aquí traigo un documento gráfico:

En amarillo vemos siempre la señal de referencia. Es lo que se mete en el bus de datos durante el ciclo este que estamos analizando. Como os contaba, he aislado una de las direcciones, es decir, se ve lo que se mete en el bus de datos, pero no lo que ya hay en el bus de datos.

La zona de interés es justo la segunda mitad vertical de la pantalla, donde vemos un "valle", con ráfagas de pulsos. Esos pulsos son la información de sprites viajando hacia la memoria gráfica.

1. En verde vemos el estado de una línea de direcciones cualquiera. Como veis, en la zona de interés es la señal típica de un contador (probablemente el horizontal):

2. En verde vemos la señal DIR del bus de direcciones. Como veis, las direcciones son siempre de salida (las genera la CPU, menos en el momento en cuestión, que la dirección es al revés, y las direcciones entran de fuera:

3. Ahora en verde la señal de INT de la CPU. Es muy interesante, y parece confirmar mi hipótesis. Durante la interrupción la CPU actualiza en RAM principal la información de video, y justo a continuación dicha información gráfica es llevada a las RAMs gráficas:

4. Y por último dos señales que parecen idénticas, pero no lo son, la segunda está un instante retardada con respecto a la primera. La primera es /BUSREQ, de entrada al Z80, y la segunda es el /BUSACK que a continuación genera el Z80. Como veis, se confirma que en ese ciclo de estudio el Z80 se "desactiva", dejando el control de los buses a circuitos externos:

No conocía este modo de funcionamiento del Z80. En futuras reparaciones habrá que estar pendientes también de este tema

Un saludo.

[ArcadeHacker]

Buen analisis, tienes un poder especial para el oscilo. 

[Marcos75]

En realidad es más un tema de "horas de vuelo".

Ya he solucionado el problema de las rayas que comentaba. Lo había provocado yo. Si alguien había puesto el puente de resistencias que os comentaba (parece incluso de fábrica), sería por algo. Lo he vuelto a poner, y todo se ve perfecto. Ahí me pasé de listo al quitarlo.

Un saludo.

[Rockman]

Muchas gracias Marcos, por el publireportaje que has hecho incluso con un ayudante. :-)

Hasta podrías ver exactamente el lapso de tiempo que necesita el Z80, entre la llamada a su pin /BUSREQ y la activación del /BUSACK conforme esta lista para "desengancharse" del bus. Parecen unos pocos microsegundos.

El tema es ver como el propio Z80 "prepara" a si mismo la operación para que los contadores hagan de bus de direcciones para que realicen esa operación, para luego devolverle el control al Z80. ¿O es alguien el que controla esa operación de desenganchar al Z80 y volverlo a enganchar?
Digo yo que igual con alguna PLD gestionara la logica de esta operación, si no hay otro procesador que lo haga. Puede que las interrupciones tengan un papel muy importante en la operación.

Leyendote Marcos se me genera la pregunta del millón y es: ¿Porqué tiene que realizar esa operación desenganchandose del Z80?
Será por tema de velocidad o realiza la operación más deprisa que si tuviera el control el Z80?

Edcross tu puedes interpretar esa operación como la hacen desde el driver de Mame?

Mirando la documentación del driver comentan esto, que no estoy seguro si tiene que ver con el tema de las interrupciones y al tema que comenta Marcos:

Código: [Seleccionar]

2) CPU.

The board has a single? crystal @12.000 MHz.
Both CPU clocks run at 3MHz (12/4).

The main Z80 runs in Interrupt mode 0 (IM0), the game program expects
execution of two different restart (RST) instructions.
RST 10,the main IRQ, is to be triggered each time the screen is refreshed.
RST 08 must be triggered in order to make the game work properly. I haven't
ascertained the exact frequency of this interrupt yet, though the game
appears to run at the correct speed with RST08 at 30Hz. Curiously a trace
on the interrupt pin shows two interrupts occuring at 60Hz, obviously the
VBlank interrupt followed by a second interrupt some 3.3ms later. At some
stage I'll get around to probing the data lines to find the interrupt
vector addresses.
Una de estas interrupciones RST08 es la que has "cazado" en tu osciloscopio?

Saludos y disculpas si digo incongruencias! :-P

[Marcos75]

Hola Rockman.

Yo no he visto esa segunda interrupción, aunque ahora que lo dices creo que la intuyo: el ancho del pulso de interrupción es "oscilante". En principio lo achaqué a una simple variación de tiempos, pero está claro que lo que estaba viendo eran dos pulsos distintos alternándose muy rápidamente.

Esto que aquí se dice puede tener que ver con el chip de protección. Quizá sea ese el que ejecuta y controla esa segunda interrupción.

Un saludo.

[Rockman]

Mmm no se Marcos, en el driver también hablan de la protección del juego aquí:

Código: [Seleccionar]

The 68705 MCU handles the two coin inputs and drives the MSM5205 ADPCM chip.
It also appears to serve as a simple protection device. During initialization,
the main Z80 writes a special ADPCM code to the MCU and then spins in a loop.
The MCU reponds by asserting the Z80's /NMI line, and thus the init process
continues. The protection ADPCM code varies between versions of each game.

Iba a escribir que no tiene que ver pero ya estoy dudando. Dice que el microcontrolador entra en un bucle, pero creo entender que solo se usa en la inicializacion del juego. O ese bucle es el que determina esta interrupción ?¿
Entonces el sentido de todo esto sería la protección que tiene el juego?

Creo que estamos profundizando pelín demasiado, y yo por lo menos, sin saber demasiado al respecto... :-P

[Marcos75]

Yo creo que tienes tú razón, y que únicamente utiliza eso en el arranque. De hecho, la bootleg simula la MCU con un aéreo, y cuando arranca suena una voz, cosa que no hace la original. Mi suposición viene de que revisando el aéreo de la bootleg vi por ahí alguna señal de baja frecuencia, pero no creo que tenga nada que ver con las interrupciones.

Luego está la encriptación del juego, que también la tiene.

Un saludo.

[ricky2001]

Yo flipo con vosotros, Marcos me quito el sombrero, es impresionante el nivel que tienes 

Saludos

[Characa]

Sublime Marcos, eres TELECO verdad?