This post is first in English and then in Spanish
Esta noticia está primero en inglés y luego en español

World Rally emulation is complete. I implemented priorities (that were trickier than I thought), shadows/highlights and a few missing bits in the video hardware. Here are some screenshots of the finished driver:

The game is fully playable from beginning to end without any problem as far as I can tell. I thought there was a bug in the video hardware emulation somewhere when I saw this:

So I plugged my PCB and compared it to the driver:

The problem is also in the original arcade game. Because of the way an arcade monitor works, the problem is nearly unnoticeable in the original game. I also checked if the original PCB had the same “shadow effect” for the tiles:

As you can see, the hardware works that way:

 
Something curious about the protection... Javier told ElSemi that the protection of this game took 8 months of work, so imagine how complicated it was… even the dallas has some code that performs some pseudorandom dummy accesses to the shared RAM to make black box attacks even more difficult.

To clarify a question about the other protected games, having the World Rally dallas code does not help to emulate the protection of them.  As MAME now has a DS5002FP core and the other games are almost fully emulated, if we get the dallas code for a game, it will be playable quickly.

Finally, I want to thank to all the people that made this possible. It was cool to be part of this. It has brought me some good memories and healed my wounds with Gaelco.

Update: Gaelco made public the ROMs for World Rally. You can get them from their web page

For reference here are all the posts about World Rally emulation:

Part 1
Part 2
Part 3
Part 4

Es completamente  jugable sin que haya podido observar ningún problema. Pensé que había algún fallo en la emulación del hardware gráfico cuando vi esto:

Así que enchufé mi placa y la comparé al driver:

Como se observa, el problema también está presente en el juego original. Debido a la forma en la que funciona un monitor de recreativa, el pequeño fallo gráfico es prácticamente inapreciable en el juego original. También comprobé si el juego original hacía el mismo “efecto de sombra” de los puentes:

Como se puede apreciar, el hardware funciona de esa manera:

Algo curioso sobre la protección… Javier le dijo a ElSemi que la desarrollar protección del juego llevó 8 meses de trabajo. Inmaginad cómo de complicada es la protección… Incluso el dallas tiene código para realizar accesos pseudoaleatorios a la memoria compartido con el único motivo de hacer que los ataques de tipo caja negra sean incluso más difíciles.

Sobre la pregunta de si tener el código del dallas para el World Rally sirve para emular la protección de los otros juegos, la respuesta es que no. Se necesita el código de cada uno para hacerlo funcionar. Como ahora el MAME ya dispone de un emulador de DS5002FP y los juegos de Gaelco protegidos están ya emulados completamente, una vez que obtengamos el código del dallas para un juego, será jugable rápidamente.

Por último, me gustaría darle las gracias a toda la gente que ha hecho esto posible. Ha sido muy interesante poder formar parte de esto. Me ha traído muy gratos recuerdos y ha cerrado viejas heridas con Gaelco.

Actualización: Gaelco ha hecho públicas las ROMs del World Rally. Puedes obtenerlas desde su página web

A modo de referencia, aquí están todas las noticias sobre la emulación del World Rally:

Parte 1
Parte 2
Parte 3
Parte 4

This post is first in english and then in spanish.
Esta noticia está primero en inglés y luego en castellano.

Javier sent us (via ElSemi) detailed information about how the encryption process worked. However, he told us that the sheets of paper that contained the encryption info were a bit difficult to read in some places (remember that this protection was designed 15 years ago) so probably there was some mistakes in the excel file he sent us. ElSemi and I tried to add it with the information he gave us but we didn’t have success. Nicola Salmoria did an excellent work (as always) consolidating the information and obtaining the missing information. He generated a working decryption function that not only works for World Rally, but also for Squash and Thunder Hoop.

Mike Coates also completed the interface to get the data from a World Rally PCB, so he was able to supply the encrypted/decrypted data that was needed to get the specific details to decrypt World Rally properly.

Special mention to Andreas Naive too. The high level information Javier told us a few days ago was already discovered by Andreas and posted in his page a couple of months ago. Before Javier sent us detailed information about how the encryption worked I contacted Andreas Naive about the encryption and he told me that he didn’t have free time at the moment to look at it. However he told me an intuition he had about the algorithm:

"I remember that my last feeling was that to decipher each 16 bits block, it was done in 3 chunks: a first 6 bits chunk and then two 5 bits chunks, each of them based in a/some bits of the first chunk. I don't remember exactly which ones, but the first chunk was the one with a simple structure (based on the tables I published), while the other two were the ones that shown a more complex structure (and carry effects)".
He was completely right as that was how it worked the encryption that Javier sent us.
 
It is good to have geniouses around ;-)

After adding the decryption to the driver the game looks like this:

It has a few graphic glitches that will be fixed soon but it seems to be PLAYABLE ;-)

Update: more progress has been made. You can read about it here

Javier nos ha mandado (via ElSemi) información detallada sobre cómo funciona el proceso de encriptación. Sin embargo, las hojas donde tenía detallado el funcionamiento del algoritmo eran difíciles de leer en algunos sitios (ya que la protección fue diseñada hace 15 años) por lo que probablemente habría alguna errata en el fichero Excel que nos mandó.  ElSemi y yo intentamos en vano añadir la información de Javier. Nicola Salmoria ha realizado un trabajo excelente (como siempre) terminando de pulir esa información y descubrir los detalles que faltaban. El ha implementado una función de desencriptación que funciona no solo para el World Rally, sino también para el Squash y el Thunder Hoop.

Mike Coates terminó el interfaz para obtener datos de la placa del World Rally, suministrando valores encriptados y sus correspondientes valores desencriptados, que permitieron obtener los datos específicos necesarios para la correcta desencriptación del World Rally.

Mención especial a Andreas Naive. La información de alto nivel que Javier nos dio hace unos días ya había sido descubierta por Andreas, que la publicó en su página hace unos meses. Antes de que Javier nos diera la información detallada sobre cómo funcionaba la encriptación, contacté con Andreas Naive sobre el tema. Me dijo que ahora mismo no tenía tiempo disponible para mirarlo. Sin embargo, me dijo que tenía un pálpito:

“Al descifrar cada bloque de 16 bits, se hacía en tres trozos: un primer bloque de 6 bits y luego dos bloques de 5 bits, cada uno de ellos basados en un/unos bits del primer bloque. No recuerdo cuáles eran cuáles, pero el primer bloque era el que tenía una estructura más sencilla (según las tablas que publiqué), mientras que los otros dos son los que mostraban estructura más compleja (y efectos de acarreo debidos a alguna suma).”

El algoritmo que nos había mandado Javier funciona exactamente de esa forma.

Está bien estar rodeado de genios ;-)

Después de añadir el algoritmo para desencriptar los datos, el juego mostraba este aspecto:

El juego tiene algunos fallos gráficos que se corregirán pronto pero es JUGABLE (lo poco que he probado) ;-)

Update: se ha completado la emulación del World Rally. Puedes leer sobre ello aquí

This post is first in English and then in Spanish
Esta noticia está primero en inglés y luego en español

The Dallas DS5002FP core is complete. The additions to the 8051 core are:

- Extra Special Function Registers
- Byte-wide Bus Support
- Memory Partition and Memory Range
- Bootstrap Configuration
- Power Fail Interrupt
- Timed Access
- Stop Mode
- Idle Mode

I didn’t bother to add support for Peripherals, the Reprogrammable Peripheral Controller or CRC-16 support because it isn’t used by the game.

The communication between the Dallas and the main CPU seems to be working, however, the game writes some bytes to the encrypted Video RAM, it reads them back and then makes some calls based on the decrypted data. As the current decryption is wrong, the game doesn’t work yet and never uses the dallas for anything interesting right now.

The decryption of the Video RAM is in the same state as it was. However, ElSemi asked Javier for information about the decryption and he is trying to help us. He didn’t remember how it was performed but we send him the information we got about it in 2002 (when Mike connected the PCB to the fluke) to refresh a bit his memory. Thanks to that, he gave us another point of view about how the encryption may work. Even if he is right, we still need to get data from the original PCB. Hopefully, somewhere in the process we end up with a clean decrypt function that uses no tables.

Understanding some code I was able to guess some decrypted values and get this:

It looks really ugly as the colors for the tiles aren’t decrypted properly but this finally confirms that World Rally uses the same Video Hardware as Target Hits. The only change seems to be the additional palette entries for the night races. I have seen how the palette was configured in a night race and I have an idea of how the palette works for the night races (not very different from World Rally 2), but we’ll have to wait until the game works to implement it.

So, the current status is that if the Video RAM is decrypted properly and we are lucky, the game should work without the light effects (and maybe some priority problems) and be playable. If we are not that lucky, hopefully the problems are not difficult to find and fix.

Update: more progress has been made. You can read about it here

El emulador del Dallas DS5002FP está completado. Lo que se ha añadido al emulador del 8051es:

- Registros de funciones especiales (SFRs) extra
- Soporte del Byte-wide bus
- Partición y Rango de memoria
- Configuration de arranque
- Interrupción por falta de energía
- Acceso temporizado
- Modo Stop
- Modo Idle

No he añadido soporte de periféricos ni el Controlador Reprogramable de Periféricos, porque no son usados por el juego.

La comunicación entre el Dallas y la CPU principal parece estar funcionando correctamente. Sin embargo, el juego escribe algunos bytes a la memoria de Video encriptada, luego los lee desencriptados y hace unos saltos dependiendo del valor desencriptado. Como la desencriptación actual es incorrecta, el juego sigue sin funcionar todavía y no utiliza el dallas para nada interesante todavía.

La desencriptación de la memoria de Video sigue igual. Sin embargo, ElSemi le ha pedido a Javier información sobre la encriptación y nos está tratando de ayudar. Javier no recordaba cómo funcionaba la encriptación por lo que le hemos mandado la información que obtuvimos en 2002 (cuando Mike conectó la placa al fluke) para refrescar su memoria. Gracias a ello, Javier nos ha dado otro punto de vista de cómo podría funcionar la encriptación. Aún si está en lo cierto, con lo que nos ha dicho aún necesitamos obtener datos de la placa original. Con un poco de suerte, en algún momento terminaremos con una función de desencriptación clara que no usa tablas.

Entendiendo un poco de código he podido intuir unos cuantos valores desencriptados y obtener esto:

Se ve realmente feo porque los colores de los bloques no están desencriptados correctamente pero esto confirma finalmente que el World Rally utiliza el mismo hardware gráfico que el Target Hits. El único cambio son unas entradas adicionales de la paleta para las carreras nocturnas. He podido ver como se configuraba la paleta en una carrera nocturna y tengo una idea de cómo va (parecido al World Rally 2), pero habrá que esperar a que el juego funcione para poder implementarlo.

Por lo tanto, el estado actual es que si la RAM de Video se desencripta correctamente y tenemos un poco de suerte, el juego debería funcionar sin los efectos de luz (y quizás con algún problema de prioridades), pero sería jugable. Si no somos tan afortunados, con un poco más de trabajo encontraremos y arreglaremos los problemas que surjan.

Actualización: se ha avanzado un poco más. Puedes leer sobre ello aquí

This post is first in English and then in Spanish
Esta noticia está primero en inglés y luego en español

If you have tried to execute World Rally since it was added to MAME you have seen the precarious state of the driver. The protection of World Rally is double:

Encrypted Video RAM:

The encrypted Video RAM transforms a 32 bits value written to it to another value that is really complex to derive from the original value. This protection was also used in Thunder Hoop and Squash. Mike Coates connected a fluke to his PCBs and got a 4 GB file will all possible combinations (2^32) for Thunder Hoop and Squash.  Using that file, the encryption process was replicated.  However, it was not very practical to require a 16 GB file to run the game. Nicola Salmoria studied the file and generated some code (about 400 lines) that replicated the original encryption. That’s why you can play Thunder Hoop and Squash.

Why World Rally encryption is incomplete? All of us wanted to see World Rally running before any other game, so we started studying World Rally before Squash and Thunder Hoop. In that time, we thought that the encryption was only performed in 16 bits, not 32. Unfortunately, when Mike got all decrypted values (2^16), the code was clearly showing that the decrypted values were not correct in most cases (for example, one of the methods that draws the tiles uses a decrypted value for the number of tiles to draw. That’s why the power on self test results and other screens look horrible right now).  After we find that out, the decryption efforts were centered in the other games. As World Rally was not going to be playable unless the dallas code was dumped (something that seemed unlikely), it has remained that way.

Dallas DS5002FP secure MCU:

The Dallas MCU in the Gaelco games has some critical code that handles inputs, objects manipulation and other complex calculations that prevent the game from working properly (Take a look at World Rally 2 if you don’t know what I mean). The DS5002FP MCU has been one of the best chips for protecting information on its era making emulation of these games impossible for now. There are some specialized labs that claim to be able to get the code from a DS5002FP but it is an incredibly expensive process we can’t afford.

I have to admit that I thought that I’d never see World Rally emulated, as I approached some people at Gaelco and Zigurat for the Dallas code without luck. However, the other day I received an email that changed my mind. Miguel Angel Horna (ElSemi) did a talk at Lleida Lan Party about emulation. At the party he met one of the Gaelco founders (Javier Valero) that was there to speak about the arcade game industry. ElSemi and Javier talked about the protection in some Gaelco games and Javier was kind enough to provide the dallas code for World Rally. With the internal code of the DS5002FP it is just a matter of time to finally have a working driver in MAME.

I have been completely inactive from MAME development for a while but as I worked on the drivers of all the Gaelco 2D games (except Master Boy) and I spent a lot of time and money on them, I thought it was a good time to resume my work on MAME.

Mike Coates is trying to get all the possible values from World Rally Video RAM so we can advance in that area too.

Currently I am writing a DS5002FP core to run the dallas code. The DS5002FP is just a 8051 MCU with some additions and as MAME already has a 8051 core things are going fast. For example, the initial coprocessor test works (although it is a trivial test to pass without the dallas code):

Also, adding the Power Fail Interrupt of the dallas I managed to see this screen that is supposed to be seen when the dallas is dying:

After the both protections are emulated the driver will need more work as probably the video hardware emulation isn’t complete and needs some tweaks here and there but I’m confident that World Rally will be playable in a not so distant future. I don’t know if Javier will give us more dallas code or not, but hats off to him for this one. Also, thanks a lot to ElSemi for being able to get the dallas code from him.

Update: more progress has been made. You can read about it here

Si has tratado de ejecutar el World Rally desde que fue añadido al MAME habrás visto el estado tan precario del driver. La protección del World Rally es doble:

Memoria de Video Encriptada:

La memoria de video encriptada transforma los valores de 32 bits que se escriben en ella, de forma que el valor resultante es extremadamente difícil de obtenerlo dado el valor original. Esta protección también se utilizó en el Thunder Hoop y en el Squash. Mike Coates conecto un fluke a su placa y obtuvo un archivo de 4 GB con todas las combinaciones posibles (2^32). Usando ese archivo, se pudo replicar la encriptación. Sin embargo, no era muy práctico necesitar un archivo de 16 GB para ejecutar el juego. Nicola Salmoria estudió el archivo y obtuvo un código (cerca de 400 líneas) que obtenía los mismos valores de la encriptación. Por ello se puede jugar al Thunder Hoop y al Squash actualmente.

¿Por qué la encriptación del World Rally está incompleta? Todos queríamos ver el World Rally funcionando antes que cualquier otro juego, por lo que empezamos a estudiar el World Rally antes que el Squash y el Thunder Hoop. En esa época, pensábamos que la encriptación solo era de 16 bits, no de 32. Cuando Mike obtuvo los valores desencriptados (2^16) pudimos comprobar la cruda realidad. El código mostraba claramente que los valores desencriptados no eran correctos en la mayoría de los casos (por ejemplo, uno de los métodos que dibuja los fondos de las pantallas usa un valor desencriptado como el número de bloques a dibujar. Por eso la carta de ajuste inicial que muestra los resultados de los tests iniciales se ve tan mal actualmente). Después de percatarnos de nuestro error, los esfuerzos se centraron en el resto de juegos. Como el World Rally no iba a ser jugable a no ser que el código del dallas se obtuviera  (cosa que parecía altamente improbable), se ha mantenido como estaba.

Microcontrollador Dallas DS5002FP:

El Microcontrolador Dallas en los juegos de Gaelco contiene código crítico que maneja la entradas de los jugadores, la manipulación de objetos u otros cálculos complejos que hacen que los juegos no funcionen correctamente (prueba el World Rally 2 si no sabes a lo que me refiero). El DS5002FP ha sido uno de los chips con más éxito a la hora de proteger información en su época, haciendo que la emulación de estos juegos fuera imposible. Hay laboratorios especializados que presumen de poder obtener el código de un DS5002FP pero es un proceso increíblemente caro que no nos podemos permitir.

Debo admitir que pensé que nunca vería el Word Rally emulado, ya que contacté con varias personas de Gaelco y Zigurat preguntando por el código del Dallas pero no hubo suerte en ese momento. Sin embargo, el otro día recibí un email que me hizo cambiar de opinión. Miguel Angel Horna (ElSemi) dio una charla en la Lleida Lan Party sobre emulación. En la party conoció a uno de los fundadores de Gaelco (Javier Valero) que estaba allí para hablar acerca de la industria de los juegos recreativos. ElSemi y Javier hablaron sobre la protección en algunos juegos de Gaelco y Javier tuvo el detalle de dar el código del dallas que usa el World Rally. Con el código interno del DS5002FP es sólo una cuestión de tiempo de que finalmente el juego pueda funcionar correctamente en el MAME.

He estado completamente inactivo en el desarrollo de cosas para el MAME bastante tiempo, pero como trabajé en los drivers de todos los juegos 2D de Gaelco (excepto el Master Boy) y me he dejado un montón de tiempo y dinero en ellos, he pensado que sería un buen momento para trabajar un poco más en el MAME.

Mike Coates está tratando de obtener los posibles valores de la memoria encriptada del World Rally para ir avanzando en ese aspecto.

Por mi parte, estoy escribiendo un core para el procesador DS5002FP de forma que se pueda ejecutar el código del dallas en MAME. El DS5002FP es un microcontrolador 8051 con ligeros cambios, y como ya hay un core del 8051 en MAME, la cosa avanza rápido. Por ejemplo, las comprobaciones iniciales del coprocesador funcionan (aunque es un test tan sencillo, que se puede parchear sin tener el código del dallas, pero bueno):

Emulando la interrupción de fallo de tension del dallas, he conseguido ver esta pantalla que se muestra cuando se le acaba la pila al dallas y su contenido deja de funcionar:

Después de que ámbas protecciones hayan sido emuladas el driver necesitara un poco más de trabajo porque probablemente la emulación de video requiera unas mejoras pero estoy convencido de que el World Rally será jugable en un futuro no muy lejano. No se si Javier nos pasará más códigos del dallas para otros juegos o no, pero me quito el sombrero por lo que ya nos ha dado. Muchísimas gracias a ElSemi por conseguir el código del Dallas.

Actualización: se ha avanzado un poco más. Puedes leer sobre ello aquí

Nicola Salmoria was able to decrypt a complete CPS2 game algorithmically without using any table!

Well, to be fair Andreas Naive played a key role here. Andreas started with the Feistel Network theory and lead the break out. It is amazing what you can get making two genius work together!

In case you haven't heard of Andreas, he's a very clever spanish guy that also helped to reverse engineer the DSP-1 chip used in Mario Kart and the S-DD1 used in Star Ocean.

There are some pieces of the puzzle to complete to fully understand the encryption but having reached that far it can only get better ;-)

Take a detailed look at their blogs to know more about this amazing achievement!

http://andreasnaive.blogspot.com/

http://mamelife.blogspot.com/

Hats off to you guys!

Another year ends and a new one comes. Life goes as fast as usual and we’re keep on our way. It’s time to think about it… our actions, hopes, wishes, mistakes, etc.

I usually listen to a special song a few minutes after the start of the year. In the last few years I have been choosing "Aerosmith – Full Circle" because it has special connotations for me.

I wish you the best in the coming year.

My girlfriend sent me this Excel spreadsheet where you have guess some old games based on the screenshots.

A funny way to spend 5 minutes. I scored 60 out of 65 (I was too young for some of the games).

There’s a bug in one name: instead of operation you have to type operación.

Have fun!

This post is first in Spanish and then in English.

Esta es la última noticia relativa al Trivial Pursuit en español. Si no has leído las noticias anteriores puedes hacerlo aquí:

http://www.manuelabadia.com/blog/PermaLink,guid,bce41855-2806-40e2-b956-e45ba07b3215.aspx

http://www.manuelabadia.com/blog/PermaLink,guid,8e5e772a-5769-4741-b59a-d99a89e3e285.aspx

De la última semana teníamos la siguiente configuración de las ROMs:
0x10000-0x13fff ???
0x14000-0x17fff ???
0x18000-0x1bfff ???
0x1c000-0x1ffff TP_A5.BIN
0x20000-0x23fff ???
0x24000-0x27fff TP_A1.BIN
0x28000-0x2bfff ???
0x2c000-0x2ffff TP_A3.BIN

y ya sabíamos como iba la rutina que mostraba las frases en pantalla.

Si continuamos entendiendo el código, llegamos al bucle principal del juego, donde se realiza una serie de tareas determinadas por el estado actual.
Estudiando los diferentes estados del juego podemos averiguar cualquier cosa que queramos sobre él. Os adjunto una captura de los distintos estados del juego:

Si estudiamos el estado cuando la variable vale 0x04, es decir, cuando se muestra una pregunta, llegamos al fin a la rutina que muestra las preguntas por pantalla (dicha rutina está en $f390). Esta rutina es bastante larga y compleja, por lo que no la voy a detallar. Sin embargo, resulta curioso saber cómo se guardan las preguntas y las respuestas del juego.

Las preguntas se guardan con 2 punteros. El primero indica el tipo de pregunta que es y el segundo la pregunta en si. Un ejemplo deja esto más claro: La pregunta: "¿Cual fue el primer monarca europeo que visitó china?" tiene un puntero a "Cual" y a "fue el primer monarca europeo que visitó china". Gracias a este esquema se ahorran unos cuantos bytes puesto que todas las preguntas empiezan por un conjunto reducido de frases del tipo Cuándo, Qué, Quién, De quienes, etc. Esto es solo la primera parte, puesto que los punteros apuntan a frases que tienen los caracteres codificados en base 40, de forma que en 2 bytes se pueden meter 3 caracteres. De nuevo un ejemplo es lo mejor para entender esto.
 
Si tenemos los bytes:
0x42 0x80 0x55 0x27
 
los agrupamos de 2 en 2 y para cada 2 bytes obtenemos los 3 dígitos que componen ese número en base 40. Por si no andáis muy puestos en cambios de base, si quisiéramos obtener los dígitos que componen el número 379 en base 10, obtendríamos 3, 7 y 9, puesto que 379 dividido entre 10^2 da 3 y de resto 79. 79 dividido entre 10^1 da 7 y de resto 9, y 9 entre 10^0 da 9, es decir, 379 = 3*10^2 + 7*10^1 + 9*10^0.

Para base 40 es similar pero dividiendo entre 40. Para el número 0x4280 obtenemos 10, 25 y 24 (en hexadecimal 0x0a, 0x19 y 0x18), y para 0x5527 obtenemos 13, 24 y 39 (en hexadecimal 0x0d, 0x18 y 0x27).

Una vez que se obtienen los 3 dígitos de los 2 bytes, se mandan a la rutina que vimos la semana pasada para mostrar frases por pantalla, aunque se hace un ligero ajuste al principio. Si recordáis lo que dije la semana pasada, la rutina para mostrar caracteres por pantalla hacía la siguiente conversión:
0x00-0x09 -> números del 0 al 9
0x0a-0x23 -> caracteres de la 'a' a la 'z'
0x27-> espacio
0x32-0x4b -> caracteres de la 'A' a la 'Z'

Si comprobamos los valores que habíamos obtenido anteriormente, tenemos:
0x0a -> a, 0x19 -> p, 0x18 -> o, 0x0d -> d, 0x18 -> o, 0x27 -> espacio en blanco
por lo que los bytes 0x42 0x80 0x55 0x27 codifican "apodo ".

Como el juego guarda los caracteres a imprimir en base 40, tan solo se dispone de 40 caracteres distintos para representar las preguntas. Sin embargo, los números más las letras en minúscula ya hacen un total de 36 valores distintos, por lo que no habría forma de mostrar mayúsculas ni todos los acentos así como signos de puntuación. Para evitar este problema, el juego utiliza el valor 0x24 como marcador para indicar que el siguiente byte que se lea se escribirá sumándole 0x28, de forma que si quisiéramos escribir Apodo en vez de apodo deberíamos tener los valores:
0x28 0x0a 0x19 0x18 0x0d 0x18

Una vez entendido esto, no tenemos más que creamos un programa en C# que muestre todas las frases que encuentre en las ROMs:

Al ejecutar el programa obtenemos muchas preguntas y respuestas en varias ROMs:

[...]

39a: nombre dieron los romanos a las islas canarias
3bb: llamamos en espa#ol a la ciudad alemana de koln
3de: de los ap3stoles alfab1ticamente es el primero
3ff: lugar est0 #la creaci3n del hombre# de miguel angel
426: de los evangelios cuenta que un ni#o le llev3 a jes4s 5 panes y 2 peces
45b: dos paises hay cadenas monta#osas llamadas sierra nevada
484: tienen como patr3n a san nicol0s
49d: hero2na se abras3 en 1431
4b0: continente no tiene ciudades capitales

[...]

8FB: australiana
904: ava gardner
90F: sara montiel
91A: gina lollobrigida
929: brigitte bardot
936: susana estrada
943: arthur miller
94E: hern0ndez mancha
95D: john ford
966: juan pablo ii
973: ernesto iv

[...]

Por lo que ya tenemos un poco más claro que hay en las ROMs que no tenemos mapeadas correctamente:
TP_A2.BIN -> preguntas
TP_A4.BIN -> respuestas
TP_A6.BIN -> ni preguntas ni respuestas, sino que hay datos de otro tipo
TP_A7.BIN -> preguntas y respuestas
TP_A8.BIN -> preguntas y respuestas

La misma rutina que decodifica las preguntas utiliza 2 bancos distintos para obtener los punteros que forman la preguntas y sus respuestas, 4 bancos distintos para obtener el texto de las preguntas y otros 4 bancos distintos para obtener el texto de las respuestas. Como cada ROM tiene 2 bancos, gracias a la información obtenida tenemos:

La ROM TP_A6.BIN ya está mapeada correctamente.
Para las preguntas tenemos 4 opciones y para las respuestas otras 4 opciones por lo que el número total de combinaciones queda reducido a 8. El único problema es que la máquina tiene un generador de números aleatorios, por lo que si nos decantamos por la opción de probar las 8 combinaciones distintas, tenemos que trucar el generador de números aleatorios para que siempre estemos probando colocar las ROMs para la misma pregunta.

Tras 3 o 4 pruebas al fín obtenemos la combinación correcta:

0x10000-0x13fff TP_A2.BIN
0x14000-0x17fff TP_A7.BIN
0x18000-0x1bfff TP_A4.BIN
0x1c000-0x1ffff TP_A5.BIN
0x20000-0x23fff TP_A8.BIN
0x24000-0x27fff TP_A1.BIN
0x28000-0x2bfff TP_A6.BIN
0x2c000-0x2ffff TP_A3.BIN

Como para acertarla sin haber estudiado el juego a fondo...

Aquí tenéis unas pantallas con el juego funcionando correctamente:

Le doy los últimos repasos al driver y lo envío a la lista del MAME.

Espero que disfrutéis del juego muy pronto. Probablemente sea mi último driver para el MAME.

This is the third post about Trivial Pursuit Spanish. If you haven't read the previous ones you can do it here:

http://www.manuelabadia.com/blog/PermaLink,guid,bce41855-2806-40e2-b956-e45ba07b3215.aspx

http://www.manuelabadia.com/blog/PermaLink,guid,8e5e772a-5769-4741-b59a-d99a89e3e285.aspx

Last week we had the following ROM configuration:
 0x10000-0x13fff ???
0x14000-0x17fff ???
0x18000-0x1bfff ???
0x1c000-0x1ffff TP_A5.BIN
0x20000-0x23fff ???
0x24000-0x27fff TP_A1.BIN
0x28000-0x2bfff ???
0x2c000-0x2ffff TP_A3.BIN

If we continue understanding code we reach the main loop of the game, where the code jumps to a routine based on the current state. Here’s the method I’m talking about:

If we carefully study what happens in the state 0x04, where the game shows a question, we finally found how the questions and answers are coded (routine at $f390). That routine is large so I’m not going to show it but it’s curious to know how the questions and answers were stored.

A question is defined by 2 pointers. The first one is the start of the question and the second one the core of the question. An example will explain this better than me: The question: “Who was the first king that visited china?” has the first pointer pointing to the sentence “Who” and the second one to “was the first king that visited china”. Thanks to this schema they save a few bytes per question.

This is only the first part as the characters for the sentences are coded in base 40. 3 characters are coded in 2 bytes. Again an example is the best to explain this:
 
If we have the following bytes:
0x42 0x80 0x55 0x27
 
We take 2 bytes at a time and extract 3 base 40 digits so for 0x4280 we’ve got 10, 25 and 24 (0x0a, 0x19 and 0x18 in hexadecimal), and for 0x5527 we’ve got 13, 24 and 39 (0x0d, 0x18 and 0x27 in hexadecimal).

After having the values, they’re sent to the routine we saw last week that printed characters. That routine did the following conversion:
0x00-0x09 -> numbers from 0 to 9
0x0a-0x23 -> characters from 'a' to 'z'
0x27-> space
0x32-0x4b -> characters from 'A' to 'Z'

If we check what we obtained previously:
0x0a -> a, 0x19 -> p, 0x18 -> o, 0x0d -> d, 0x18 -> o, 0x27 -> space
So the following bytes: 0x42 0x80 0x55 0x27 store "apodo " (spanish word for nickname).

As the game stores the characters using base 40 codification, we can store only 40 characters, but the digits and lowercase letters make a total of 36 characters and we are still missing punctuation marks, uppercase letters, etc. To solve that problem, the game uses the value 0x24 as a marker to indicate that the character will be written adding 0x28 to the next value. If we want to write Apodo instead of apodo we would need the values:
0x28 0x0a 0x19 0x18 0x0d 0x18

With this information we can write a C# program that searchs all sentences in a ROM:

If we run the program we get a lot of questions and answers in several ROMs:

[...]

39a: nombre dieron los romanos a las islas canarias
3bb: llamamos en espa#ol a la ciudad alemana de koln
3de: de los ap3stoles alfab1ticamente es el primero
3ff: lugar est0 #la creaci3n del hombre# de miguel angel
426: de los evangelios cuenta que un ni#o le llev3 a jes4s 5 panes y 2 peces
45b: dos paises hay cadenas monta#osas llamadas sierra nevada
484: tienen como patr3n a san nicol0s
49d: hero2na se abras3 en 1431
4b0: continente no tiene ciudades capitales

[...]

8FB: australiana
904: ava gardner
90F: sara montiel
91A: gina lollobrigida
929: brigitte bardot
936: susana estrada
943: arthur miller
94E: hern0ndez mancha
95D: john ford
966: juan pablo ii
973: ernesto iv

[...]

So now we know what is inside the ROMs we don’t know how to map:
TP_A2.BIN -> questions
TP_A4.BIN -> answers
TP_A6.BIN -> unknown data
TP_A7.BIN -> questions and answers
TP_A8.BIN -> questions and answers

The same routine that decodes the questions and answers uses up to 4 different banks to select a question, up to 4 different banks to select an answer and 2 banks to get the pointers to the questions and answers, so thanks to that information we can map ROM TP_A6.BIN and reduce the number of possible combinations to 8.

After a few tries we finally found the proper combination:

0x10000-0x13fff TP_A2.BIN
0x14000-0x17fff TP_A7.BIN
0x18000-0x1bfff TP_A4.BIN
0x1c000-0x1ffff TP_A5.BIN
0x20000-0x23fff TP_A8.BIN
0x24000-0x27fff TP_A1.BIN
0x28000-0x2bfff TP_A6.BIN
0x2c000-0x2ffff TP_A3.BIN

Some screenshots of the game running:

I’ll tidy up the code and send it to the MAMEDEV list.

This post is first in Spanish and then in English.

Esta es la segunda noticia relacionada con el Trivial Pursuit en español. Si no has leido la primera puedes hacerlo aquí:

http://www.manuelabadia.com/blog/PermaLink,guid,bce41855-2806-40e2-b956-e45ba07b3215.aspx

Voy a comentar en detalle el proceso que he seguido para ir reduciendo las combinaciones. Si no teneís conocimientos de arquitectura de computadores y ensamblador probablemente mucho de lo siguiente os suene a chino, pero bueno, igual a alguien le interesa o saca algo en claro... Si no os interesa, más abajo hay algunas fotos del juego.

Lo primero a hacer es comparar las ROMs con las de otro trivial para ver las semejanzas. Para ello el MAME trae una utilidad muy buena llamada ROMCMP. Comparando el trivial en español con los distintos clones y siempre he obtenido los mismos resultados:

La ROM de sonido es similar, y 2 de las 3 de gráficos iguales. La otra es similar en un 99.81% por lo que no hay ningún problema en mapear dichas ROMs. El problema lo tenemos con las 8 de programa. Ninguna tiene una concordancia mayor del 10%, y normalmente una concordancia tan baja es por tener muchos ceros o unos en alguna parte de la ROM. Normalmente si la concordancia no es mayor del 70%, no podemos afirmar nada, así que no partimos de nada a la hora de mapear las 8 ROMs de programa.

He probado colocando las ROMs de programa en orden ascendente (de la TP_A1.BIN a la TP_A8.BIN) y descendente pero no ha habido suerte. Por lo tanto, hay que buscar opciones para reducir el número de combinaciones posibles (40320).

El Trivial Pursuit usa como CPU principal un Motorola 6809 (CPU de 8 bits). Este procesador al arrancar empieza a ejecutar instrucciones en la dirección apuntada por el vector de reset, que está en 0xfffe-0xffff.

Si observais el driver, el sistema utiliza bancos de 8 KB para ir paginando por las ROMs, puesto que el espacio de direcciones de la CPU es de 64 KB y se necesita acceder a 128 KB de datos. Por lo tanto el objetivo es encontrar una ROM que se mapee en el rango de direcciones 0xe000-0xffff. Como cada ROM es de 0x4000 bytes, en cada ROM hay 2 bancos, por lo que hay que observar la parte final de cada banco a ver si contienen vectores válidos. No solo está el vector de reset, si no que hay varios como muestra la siguiente tabla:

FFF0H to FFF1H           |Reserved by Motorola               |
FFF2H to FFF3H           |SWI3 instruction interrupt vector  |
FFF4H to FFF5H           |SWI2 instruction interrupt vector  |
FFF6H to FFF7H           |Fast hardware int. vector (FIRQ)   |
FFF8H to FFF9H           |Hardware interrupt vector (IRQ)    |
FFFAH to FFFBH           |SWI instruction interrupt vector   |
FFFCH to FFFDH           |Non-maskable interrupt vector (NMI)|
FFFEH to FFFFH           |Reset vector                       |

A continuación muestro los últimos datos de cada posible banco de las ROMs asociadas a la CPU. Si os habeis enterado de la parrafada anterior sería un buen ejercicio tratar de adivinar que banco contiene el vector de arranque sin mirar la solución que está después de la imagen.

Los datos no dan lugar a dudas. Los vectores están en el primer banco de la ROM A3:

F382 F382 F382 FDA7 FBC6 F382 F382 F382

En muchos juegos basados en el M6809 el vector de reset coincide con el del SWI, SWI2 y SWI3 como pasa en el trivial.

Gracias a esto ya podemos mapear una ROM y tenemos la siguiente configuración:
0x10000-0x13fff ???
0x14000-0x17fff ???
0x18000-0x1bfff ???
0x1c000-0x1ffff ???
0x20000-0x23fff ???
0x24000-0x27fff ???
0x28000-0x2bfff ???
0x2c000-0x2ffff TP_A3.BIN

Con lo que las combinaciones posibles pasan de 40320 a 5040.

Como el trivial pursuit es un juego muy simple de programar, el código del programa está todo en esta ROM por lo que si ejecutamos el juego poniendo cualquier combinación en el resto de huecos ya podemos ver algo:

Sin embargo, el resto de ROMs necesitan estar bien mapeadas para ver todos los gráficos correctamente y sobre todo para que las preguntas y respuestas se muestren correctamente. Al probar distintas combinaciones con el resto de ROMs se observa que los gráficos de la presentación y del tablero van cambiando, por lo que tras unas pocas pruebas se consigue ver la presentación y el tablero correctamente:

La ROM TP_A5.BIN contiene información sobre los gráficos del tablero y la TP_A1.BIN información sobre los gráficos de la presentación.

De momento la configuración de las ROMs es:
0x10000-0x13fff ???
0x14000-0x17fff ???
0x18000-0x1bfff ???
0x1c000-0x1ffff TP_A5.BIN
0x20000-0x23fff ???
0x24000-0x27fff TP_A1.BIN
0x28000-0x2bfff ???
0x2c000-0x2ffff TP_A3.BIN

Con lo que las combinaciones posibles pasan de 5040 a 120. No está mal para no haberse metido a ver el código todavía.

Si vamos probando unas cuantas combinaciones vemos que no hay manera de hacer que las preguntas y las respuestas salgan bien, probablemente porque hay algún tipo de dependencia entre las ROMs que impide ver nada a no ser que la combinación introducida sea la correcta.

Si podemos averiguar que es lo que contiene cada ROM que no sabemos mapear, tenemos más puntos a nuestro favor para encontrar la combinación correcta. Si buscamos textos en las ROMs no encontramos nada inteligible, por lo que estarán codificados de alguna forma que no coincide con los caracteres ASCII (cosa que por otro lado tiene sentido, ya que si se pueden ver las preguntas y las respuestas fácilmente sería facil piratear el juego en otras plataformas puesto que la lógica del juego es mínima).

Por lo tanto, como no voy a probar las 120 combinaciones, no queda otra opción que bucear en el ensamblador... La gran mayoría de juegos tienen al principio una serie de comprobaciones de memoria y de ROMs (para comprobar que todo funciona bien) que sirven para descubrir cómo se mapean las ROMs y en qué orden. Sin embargo, el trivial tan solo tiene las comprobaciones de memoria y no las de las ROMs por lo que tan solo nos queda ir entendiendo código hasta encontrar alguna rutina que nos oriente en la colocación de las ROMs. Como he comentado antes, interesa saber que hay en cada ROM, por lo que si vamos estudiando código, llegamos a la rutina que muestra por pantalla el mensaje "Un momento por favor":

Esta rutina nos desvela que las frases se guardan de la siguiente forma:
1 byte de color + 2 bytes de dirección en pantalla + n bytes de la frase (1 byte por caracter) + 0xff (marcador de fín de frase)

Cada caracter de la frase está codificado de la siguiente forma:

0x00-0x09 -> números del 0 al 9
0x0a-0x23 -> caracteres de la 'a' a la 'z'
0x32-0x4b -> caracteres de la 'A' a la 'Z'
hay algunos caracteres más para símbolos de puntuación, acentos, eñes, etc que no especifico, pero espero que capteis la idea.

Me he creado un simple programa en C# al que le pasas una ROM y te busca todas las frases posibles en este formato (no he tenido en cuenta acentos, eñes y demás):

Desgraciadamente, las preguntas y respuestas del juego no están codificadas de esta forma. Las frases que están codificadas de esta forma son:

D21E: (23, 6E77) -> Jugadores Magistrales
D237: (23, 236F) ->  Pulse Start
D248: (23, 2323) -> Creditos
D254: (23, 2338) -> Introduzca Moneda   
D26D: (23, 2323) -> 1 Moneda 1 Juego
D281: (23, 2323) -> 2 Monedas 1 Juego
D296: (23, 2323) -> 2 Monedas 1 Juego
D2AB: (23, 2323) -> 1 Moneda 2 Juegos
D2C0: (68, 4F23) -> Juego Terminado
D2D3: (68, 686F) -> Usted est# entre los mejores
D2F3: (68, 6D77) -> C#ales son sus inicales
D30E: (68, 206F) -> Puntos
D318: (23, 2323) -> Muy bien Continue as#
D331: (53, 2323) -> Correcto o incorrecto
D34B: (23, 3943) -> Categor#a
D358: (23, 6620) -> Escenario y Pantalla
D370: (23, 6623) -> Gente y Recuerdos
D386: (23, 6623) -> Dias de Colegio
D399: (30, 3030) -> 0000
D3A1: (23, 6623) -> Ultimas Noticias
D3B6: (23, 2323) -> # 1987 Bally Sente
D3CC: (42, 586B) -> Lo siento la respuesta correcta es
D3F2: (23, 2323) -> La pr#xima vez lo sabr#
D40D: (23, 2323) -> Felicitaciones usted
D425: (23, 4523) -> es realmente un
D438: (23, 4B76) -> Maestro en Trivial Pursuit
D456: (23, 4F73) -> Su tiempo se ha acabado
D471: (23, 2023) -> Tiempo
D47B: (23, 2333) -> Baron Von Rightoften
D493: (23, 237A) -> Billie Genio
D4A4: (23, 2351) -> Cleopatra
D4B2: (53, 2323) -> Spartacus
D4BF: (53, 2375) -> Apriete Roja para cambiar de letra
D4E5: (23, 2375) -> Apriete Verde para fijar la letra
D50A: (23, 2367) -> Apriete Verde para elegir personaje
D531: (53, 236B) -> Apriete Rojo para cambiar
D54E: (53, 236B) -> al siguiente personaje
D568: (23, 6E7A) -> Seleccione su personaje
D583: (53, 2375) -> Apriete Rojo o Verde
D59B: (23, 2323) -> Juego gratis
D5AB: (23, 6B23) ->            
D5BB: (23, 7023) -> Adaptacion del juego
D5D3: (23, 7520) -> y Software dise#o
D5E8: (23, 4223) -> Richard Adam
D5F8: (23, 4723) -> A#Anton Toca 
D60A: (23, 4C23) -> J#Fernandez S#
D61D: (23, 5723) ->             
D62E: (23, 2342) ->  MAIBESA 1987
D640: (23, 2346) ->     
D649: (53, 2323) ->             
D65A: (23, 2323) -> TRIVIAL PURSUIT  
D670: (23, 2323) -> Volumen I I I        
D68A: (23, 237A) ->                     
D6A3: (68, 6923) -> Trivial Pursuit
D6B6: (23, 5179) -> Su puntuaci#n Magistral
D6D1: (23, 5723) -> es
D6D7: (53, 2323) -> Un momento por favor
D6EF: (53, 2041) -> Jugador
D6FA: (23, 2345) -> ARCADE

y están todas en la ROM TP_A3.BIN, por lo que no hemos avanzado mucho en este sentido.

He seguido desensamblando código hasta encontrar la rutina principal del juego, que será la que nos desvele el misterio de cómo están codificadas las preguntas y las respuestas, pero eso ya será en otro rato libre que pueda encontrar. La semana que viene terminamos con la emulación del juego.

This is the second post about Trivial Pursuit Spanish. If you haven't read the first one you can do it here:

http://www.manuelabadia.com/blog/PermaLink,guid,bce41855-2806-40e2-b956-e45ba07b3215.aspx

I'm going to explain a little bit the process to reduce the number of possible combinations. This will be a little technical but it may be interesting to somebody. If you're not interested there're some screenshots below.

The first thing to do its to compare the ROMs with other sets to spot similarities. There is a pretty good utility that comes with MAME called ROMCMP that does this. The results are:

The sound ROMs and graphic ROMs are similar so we now where to map them but the program ROMs are completely different (10% of similarity or so isn’t significant. We need at least 70% to consider them similar) so we don’t have a clue for mapping the program ROMs.

I tried in ascendant order (from TP_A1.BIN to TP_A8.BIN) and in descendant order but the game doesn’t do anything, so we have to make something to reduce the total number of combinations (40320).

The game uses a Motorola 6809 (an 8 bit CPU) as the main CPU. This chip starts fetching instructions from the reset vector located at 0xfffe-0xffff.

If you look at the driver (balsente.c), the SAC-1 system uses 8 KB banks to handle all ROM data, as the CPU can access to only 64 KB at a time and the ROMs have 128 KB of data. We need to find out which ROM maps to 0xe000-0xffff to start reverse engineering code in order to reduce the number of combinations. As each ROM is 0x4000 bytes long, we have 2 possible banks per ROM. We have to check the last bytes in each bank to see if it has valid vectors that map in 0xe000-0xffff. The full vector table for the M6809 is:

FFF0H to FFF1H           |Reserved by Motorola               |
FFF2H to FFF3H           |SWI3 instruction interrupt vector  |
FFF4H to FFF5H           |SWI2 instruction interrupt vector  |
FFF6H to FFF7H           |Fast hardware int. vector (FIRQ)   |
FFF8H to FFF9H           |Hardware interrupt vector (IRQ)    |
FFFAH to FFFBH           |SWI instruction interrupt vector   |
FFFCH to FFFDH           |Non-maskable interrupt vector (NMI)|
FFFEH to FFFFH           |Reset vector                       |

I’m showing here the last bytes of each bank so you can try to identify them yourself if you’re following me:

Without a doubt the vectors are in the first bank of the ROM TP_A3.BIN:

F382 F382 F382 FDA7 FBC6 F382 F382 F382

In a lot of games based on a M6809, the reset vector is the same as SWI, SWI2 and SWI3 as happens with this game.

Thanks to this we have one ROM mapped so for now we have:
0x10000-0x13fff ???
0x14000-0x17fff ???
0x18000-0x1bfff ???
0x1c000-0x1ffff ???
0x20000-0x23fff ???
0x24000-0x27fff ???
0x28000-0x2bfff ???
0x2c000-0x2ffff TP_A3.BIN

So the possible number of combinations decreases from 40320 to 5040.

As the game logic in this game is very simple, all the code is inside TP_A3.BIN so if we run MAME now filling the unknown holes with a random combination we can see something:

Unfortunately some graphics and the questions and answers aren’t showing up properly because we haven’t mapped them in the proper order. If you keep trying a few combinations it’s easy to fix the splash screen and the board graphics. TP_A5.BIN has information about the board and TP_A1.BIN about the splash screen:

So for now we have this ROM mapping configuration:
0x10000-0x13fff ???
0x14000-0x17fff ???
0x18000-0x1bfff ???
0x1c000-0x1ffff TP_A5.BIN
0x20000-0x23fff ???
0x24000-0x27fff TP_A1.BIN
0x28000-0x2bfff ???
0x2c000-0x2ffff TP_A3.BIN

So now the possible combinations are reduced from 5040 to 120. Not bad if we consider we haven’t studied a line of code!

If we keep trying a few more combinations we realize that there’s no way to map the other ROMs in order to see more progress (unless we were lucky enough to find the proper combination).

If we could know what kind of data is in each ROM it would be helpful to find the correct mapping, so I searched for plain text in the ROM but found nothing, so they coded the sentences somehow. So as I was in a dead end and I didn’t want to try 120 different combinations it was time to run the game with the debugger and understand some code…

Unfortunately in the power on self test there isn’t a ROM check as in a lot of games. After some debugging you end up in the routine that writes a sentence to the video memory (comments are in Spanish sorry):

This routine shows how they coded this sentence in the ROM. The format is:
1 byte for color + 2 bytes for destination address + n bytes of data (1 byte per character) + 0xff (end mark)

Each character is coded this way:
0x00-0x09 -> numbers from ‘0’ to ‘9’
0x0a-0x023 -> characters from ‘a’ to ‘z’
0x32-0x4b -> characters from ‘A’ to ‘Z’
There are more entries for for punctuation, accents, tilde, etc but you get the point…

I wrote a simple C# program to find out all the sentences in a ROM to see if I could find out what kind of data a ROM has:

Unfortunately the questions and answers aren’t coded this way, so the only readable sentences I got were:
 
D21E: (23, 6E77) -> Jugadores Magistrales
D237: (23, 236F) ->  Pulse Start
D248: (23, 2323) -> Creditos
D254: (23, 2338) -> Introduzca Moneda   
D26D: (23, 2323) -> 1 Moneda 1 Juego
D281: (23, 2323) -> 2 Monedas 1 Juego
D296: (23, 2323) -> 2 Monedas 1 Juego
D2AB: (23, 2323) -> 1 Moneda 2 Juegos
D2C0: (68, 4F23) -> Juego Terminado
D2D3: (68, 686F) -> Usted est# entre los mejores
D2F3: (68, 6D77) -> C#ales son sus inicales
D30E: (68, 206F) -> Puntos
D318: (23, 2323) -> Muy bien Continue as#
D331: (53, 2323) -> Correcto o incorrecto
D34B: (23, 3943) -> Categor#a
D358: (23, 6620) -> Escenario y Pantalla
D370: (23, 6623) -> Gente y Recuerdos
D386: (23, 6623) -> Dias de Colegio
D399: (30, 3030) -> 0000
D3A1: (23, 6623) -> Ultimas Noticias
D3B6: (23, 2323) -> # 1987 Bally Sente
D3CC: (42, 586B) -> Lo siento la respuesta correcta es
D3F2: (23, 2323) -> La pr#xima vez lo sabr#
D40D: (23, 2323) -> Felicitaciones usted
D425: (23, 4523) -> es realmente un
D438: (23, 4B76) -> Maestro en Trivial Pursuit
D456: (23, 4F73) -> Su tiempo se ha acabado
D471: (23, 2023) -> Tiempo
D47B: (23, 2333) -> Baron Von Rightoften
D493: (23, 237A) -> Billie Genio
D4A4: (23, 2351) -> Cleopatra
D4B2: (53, 2323) -> Spartacus
D4BF: (53, 2375) -> Apriete Roja para cambiar de letra
D4E5: (23, 2375) -> Apriete Verde para fijar la letra
D50A: (23, 2367) -> Apriete Verde para elegir personaje
D531: (53, 236B) -> Apriete Rojo para cambiar
D54E: (53, 236B) -> al siguiente personaje
D568: (23, 6E7A) -> Seleccione su personaje
D583: (53, 2375) -> Apriete Rojo o Verde
D59B: (23, 2323) -> Juego gratis
D5AB: (23, 6B23) ->            
D5BB: (23, 7023) -> Adaptacion del juego
D5D3: (23, 7520) -> y Software dise#o
D5E8: (23, 4223) -> Richard Adam
D5F8: (23, 4723) -> A#Anton Toca 
D60A: (23, 4C23) -> J#Fernandez S#
D61D: (23, 5723) ->             
D62E: (23, 2342) ->  MAIBESA 1987
D640: (23, 2346) ->     
D649: (53, 2323) ->             
D65A: (23, 2323) -> TRIVIAL PURSUIT  
D670: (23, 2323) -> Volumen I I I        
D68A: (23, 237A) ->                     
D6A3: (68, 6923) -> Trivial Pursuit
D6B6: (23, 5179) -> Su puntuaci#n Magistral
D6D1: (23, 5723) -> es
D6D7: (53, 2323) -> Un momento por favor
D6EF: (53, 2041) -> Jugador
D6FA: (23, 2345) -> ARCADE

And all were in ROM TP_A3.BIN so this didn’t help us very much.

I continued debugging code until the main game loop, that will tell us all what we need to know to emulate the game properly. However I ran out of time for this week so until the next week I won’t be able to finish this game.

This post is in Spanish and then in English.

Tras muchos años de búsqueda, al fin he podido localizar una placa del Trivial Pursuit en castellano (gracias José Manuel). Parece mentira que este juego haya sido tan difícil de encontrar.

Aquí tenéis una foto del juego en cuestión:

Se pueden observar 2 partes principales: las placas que forman el sistema Sente SAC-1 y el cartucho del juego.

Las placas que forman el sistema Sente SAC-1 son la de la CPU, que es la placa más grande de la figura, y la de sonido, que está situada encima del cuadrante inferior derecho de la placa de la CPU, así que cuesta un poco más verla.

El cartucho del juego está a la derecha de las placas del sistema Sente SAC-1 y es donde están las ROMs del juego. Si os fijáis bien podeis observar que hay 11 ROMs en el cartucho. Las ROMs están etiquetadas como: TP_B4, TP_B5, TP_B6, TP_A1, TP_A2, TP_A3, TP_A4, TP_A5, TP_A6, TP_A7 y TP_A8. Todas las ROMs son de 16 KB.

Iré comentando un poco el proceso que sigo para conseguir tener el juego funcionando por si tenéis curiosidad sobre estos procesos tan poco documentados. Sin embargo, como el sistema sobre el que funciona el juego ya está emulado, la complejidad para emular el juego disminuye bastante.

Si observamos las ROMs de los otros trivials emulados de este sistema, podemos ver que tienen o bien 6 ROMs de programa de 16 KB o bien 8 ROMs de programa de 8 KB, y todos tienen 3 ROMs de 16 KB (o bien 6 de 8 KB).

Por lo tanto, pienso que las ROMs TP_B4, TP_B5 y TP_B6 serán los gráficos y el resto de ROMs corresponderán al código. Probablemente tenga más ROMs que el resto de juegos puesto que las frases en castellano suelen ocupar más que en inglés por lo que las preguntas ocuparán más espacio.

Si observamos el driver del sistema Sente SAC-1 (balsente.c) comprobamos como cargan las ROMs el resto de trivials (p.e. el triviasp):

 ROM_LOAD( "allsport.8a", 0x10000, 0x4000, CRC(54b7ff31) )
 ROM_LOAD( "allsport.7a", 0x14000, 0x4000, CRC(59fae9d2))
 ROM_LOAD( "allsport.6a", 0x18000, 0x4000, CRC(237b6b95))
 ROM_LOAD( "allsport.5a", 0x1c000, 0x4000, CRC(b64d7f61))
 ROM_LOAD( "allsport.3a", 0x28000, 0x4000, CRC(e45d09d6))
 ROM_LOAD( "allsport.1a", 0x2c000, 0x4000, CRC(8bb3e831))

Se puede ver que los huecos 0x20000-0x23fff y 0x24000-0x27fff están vacíos. Como nuestro juego tiene 8 ROMs de programa en vez de 6 no tendremos huecos, aunque la dificultad reside en saber en que orden hay que poner las ROMs. Si habéis echado un vistazo al driver, para el resto de trivials las ROMs se cargan en un orden lógico (de mayor a menor o viceversa), así que con un poco de suerte, para la versión española las ROMs se cargarán desde la TP_A1 a la TP_A8 o desde la TP_A8 a la TP_A1 sin dejar huecos.

Si tuviéramos mala suerte y el juego no fuera un simple intercambio de ROMs pues tendríamos que ponernos el mono de trabajo e investigar el código del programa para saber en qué posición va cada ROM o bien probar todas las combinaciones. Como el número total de combinaciones sería 8! = 8x7x6x5x4x3x2x1 = 40320, no es una opción viable tirar por este camino si las ROMs no encajan tal cual.

Como estoy muy liado, hasta este fin de semana no probaré nada de lo que os he comentado. Conforme vaya haciendo algún progreso lo pondré en el blog.

After a lot of searching, finally a Trivial Pursuit (Spanish) PCB has been found! I was really scared about finding this one because if it was difficult to find some Gaelco games that were very extended in Spain, this one could be lost for ever.

Here’s a pic of the board:

The cartdrige has the following ROMs: TP_B4, TP_B5, TP_B6, TP_A1, TP_A2, TP_A3, TP_A4, TP_A5, TP_A6, TP_A7 and TP_A8 (all the ROMs are 16 KB).

If we compare the other trivial games from the driver (balsente.c) we can see that they have 6 program roms but this one has 8. This could be because english sentences are usually shorter than Spanish ones so this one needs more room for questions.

If we check how the ROMs are mapped in the driver the proper order is given by the ROM labels either ascendant or descendant. If we’re lucky this one could fit that schema and be a simple rom swap so we can get it working without getting dirty into code.

However, if we don’t have luck there are 8! (40320) possible combinations for the ROMs so we’ll need to study some code to reduce the combinations.

As I’m busy now, I can’t look at it until the weekend.