Essentials
Subscriptions
Legal
Powered by
Edited by
Thanks to
- Andrea Musuruane
Last updated
- July 04, 2008 11:00 PM
- All times are UTC.
Just posted over at the Source Updates page is hopefully the final update to the MAME 0.125 dev cycle. It’s been a long road! Now is the time to check this out and ensure that all your favorites are still in fine working order before we lock down for MAME 0.126.
The SH-2 DRC successfully got Cyvern past the on-screen POST last night, but that revealed a problem with cycle counting that was making MAME timing and interrupts work poorly at best. I fixed that, but there’s now a bug where it crashes trying to resume after handling an interrupt. Never a shortage of fun with this stuff!
I’ve been working on a MAME UDRC frontend for the SH-2 for just under a week now. Last night it finally made it all the way through the suprnova BIOS and into the Cyvern boot code without errors (including handling interrupts). There are still several instructions left to implement before it actually shows something, but so far so good so what, right?
Before someone asks, this will speed up ST-V (and Saturn in MESS), Kaneko SuperNova, Psikyo SH-2, and CPS3. And SH-2 is a pure subset of SH-4 (aside from different boot vector semantics) so once done this frontend will make a fine starting point for an SH-4 UDRC.
Oops, a major bug crept into the last release at the last second, so without further ado, please grab the small update to MAME 0.125u8 from the Source Updates page. There will still be a u9 next week, and hopefully a 0.126 to follow shortly thereafter.
This one ended up on the backburner when I had CPS3 to work on. I’ve finally got back to it, and now it appears to work fine. Just one unemulated game in this SemiCom series now (the original ‘Magicball Fighting’)
and just as a bonus.. some nice rear action
As pointed out on Mameworld, the backgrounds used in Swat Police shown on my pages here have all been lifted from other games, mostly it would seem NeoGeo ones. (I think some of the explosions are taken from Metal Slug too)
Aggressors of Dark Kombat vs. Swat Police
Burning Fight vs. Swat Police
Art of Fighting 2 vs. Swat Police
so.. here’s the fun part, can anybody tell me where the rest of the graphics come from?
Judge Dredd (Snes) vs Swat Police
Kitsune Sniper pointed out that the Logo is a modified version of the
one from Judge Dredd on the SNES
???? vs Swat Police
???? vs Swat Police
Burning Fight vs Swat Police
From Burning Fight (thanks BBH)
Burning Fight vs Swat Police
From Burning Fight (thanks BBH)
Burning Fight vs Swat Police
BBH shows that this is a (fairly modified) version of the Burning Fight stage 1
Burning Fight vs Swat Police
BBH pointed out that this was from a Burning Fight Bonus Stage
Burning Fight vs Swat Police
Another from Burning Fight pointed out by BBH
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:
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í
Most of my work recently has been to improve the accuracy of the PlayStation CPU emulation. This hasn’t made much of a difference to any games, though if you write your own code and it runs on the emulator then it’s more likely to run on the real thing.
I’ve now moved onto writing GTE unit tests, there were a couple of games with geometry issues & I wanted to have some visible sign of progress.
This is the result of improving the data transfer between the CPU and the GTE:
There are a few GPU issues, but I’ll get to them some other time. Someone will need to write a cheat for this though, or explain to me how to beat the computer.
The clockspeed of the PSX based games in MAME has always been a little on the low side.
Mainly to make up for the lack of cache emulation and bus contention, also partly because the GTE timing isn’t emulated yet.
Due to the recent attention to crystals, there has been some investigation as to what the real clock speed should be.
Thanks to Guru’s probing we are able to say for definate what is going on.
The CPU has an internal divider and on the majority of boards is fed a 67.7376mhz clock. I have currently got MAME to report this frequency, with an internal divider of 4 to keep it roughly the same as before ( it should be 2 but I’ll leave that until the rest of the timing issues are sorted ).
Some information has been floating around for a while that has never been confirmed & now seems to be a good time. The 67mhz clock doesn’t appear on the namco system 12 or the later system 10 boards. It appears they have their own higher rated part. System 12 runs on a 100mhz clock, while system 10 runs on a 101.4912mhz clock. So system 12 being faster has been elevated from rumour, to probable.
The GPU clock is the same across all hardware. I’d have thought they’d have done something about that, especially as all the system 12 games like to run in interlace. Maybe it’s more efficient or has faster ram, we’ll leave that one for another day.
Well,got some new ST-V games to boot thanks to a better understanding of the IC13 rom loading:
Find Love
Well this is just to post something,as I got several complainings about not being in MAME for a while… 
This is Filetto running past the title screens,I guess that this game is missing IRQs so it’s not working due of that.
Posted by Nicola Salmoria (noreply@blogger.com) at February 17, 2007 12:39 PM
Posted by Nicola Salmoria (noreply@blogger.com) at February 17, 2007 10:33 AM
Posted by Knarfian (noreply@blogger.com) at May 08, 2006 02:32 PM
Posted by Knarfian (noreply@blogger.com) at May 08, 2006 02:30 PM