Hola a todos.

Haciendo memoria tras revisar el hilo de edcross acerca de los problemas en los sprites de su Terra Cresta (http://www.aumap.org/foro/index.php?topic=2059.msg17351#msg17351), he recordado que tengo yo esta Gun.Somke con un problema muy similar: los sprites están bien formados, se mueven bien, pero sus colores son erróneos.



Además, según el código fuente de MAME, ambas placas (Gun.Smoke y Terra Cresta) gestionan los colores de forma muy similar: tres PROMs para la paleta general (RGB) y una PROM específica para la paleta de sprites (paleta estática, no dinámica, pues).

Ya en su día identifiqué las PROMs 8 y 9 como puntos a revisar. Atendiendo a MAME una es precisamente la paleta de colores, y la otra es la tabla de búsqueda de los sprites. Voy a suponer que las PROMs están bien (por no desoldarlas), y voy a revisar los integrados a su entrada, y sobre todo, a su salida, entre la PROM de la paleta de los sprites y la mezcla de colores final.

Un saludo.

Gracias Ricardo, lo tendré muy en cuenta.

De todas formas, creo que parte de lo que he dicho arriba no es correcto. He estado revisando los esquemáticos del 1943, que si bien tiene customs e historias, también usa un sistema de PROMs muy similar al del Gun.Smoke.

Resulta que estas placas que llevan una paleta específica para sprites, no es una paleta como tal, es decir, no se enchufa directamente a las salidas RGB, sino que contribuyen a direccionar la paleta final.

En definitiva, esta paleta se sitúa antes del doble buffer de sprites. El doble buffer, como su nombre indica, es un circuito que lleva "hardware" duplicado, con lo que si el error estuviese aquí se notaría solamente en líneas alternas, y no en todos los sprites. Por tanto lo que creo que está pasando es que o bien la PROM está mal, o bien hay un error ANTES (no DESPUÉS como dije antes) de esa PROM. Es decir, quizá en quien le esté sirviendo las direcciones.

Un saludo.

La paleta puede ser o estática o dinámica.

Una paleta dinámica se implementa utilizando RAMs, que pueden ser escritas durante el transcurso del juego. Eso quiere decir que, dependiendo por ejemplo de la fase del juego, o incluso de si estamos hablando de fondos o sprites, se puede utilizar unos colores u otros.

Una paleta estática sin embargo se suele implementar con PROMs. En este caso es una paleta "hardware", con lo cual los colores no se pueden modificar durante la partida.

Por ejemplo, Ghosts and Goblins lleva paleta dinámica, y Gun.Smoke, similar, lleva paleta estática.

Un saludo.

Ayer no tuve tiempo de mirar casi nada, pero lo justo para darme cuenta de que estaba equivocado en los últimos mensajes, y acertado en el primero. Intercambiando placas con la original que tengo, resulta que el problema no está en la placa de video, sino en la de CPU, con lo que está en la mezcla de colores.

Sabía seguro que no estaba en la parte desdoblada del buffer de líneas (doble buffer), porque el problema se manifiesta en todo el sprite. Por eso supuse que el problema podría estar antes, pero resulta que después, el sprite vuelve a tratarse como único antes de pasar por la paleta final. Ahí hay un multiplexor y un flip-flop que tendré que revisar (a ver si esta tarde puedo). Pero el tema parece bastante acotado.

Por otro lado, al enchufarla me di cuenta de que tenía un problema que antes no pasaba. Los sprites se ven a rayas. En estos casos el culpable suele ser una de las RAMs del doble buffer, pero las intercambié y comprobé (van en zócalo), y no eran ellas. Como en el Street Fight, el problema estaba en una etapa anterior (en las RAMs que guardan la información de los sprites. Una de las RAMs tiene sus líneas de datos fijas a Vcc. Vi que los datos se los sirve a esta RAM un 245, que estaba mal.

Un saludo.