Robin Banks gets you nowhere

If you’ve ever tried running the Sega ST-V game ‘Decathlete’ in MAME, you’ll have probably noticed it doesn’t look pretty.

Infact, aside from a few advertising banners in the 400 Meter race every single graphical element appears to be corrupt, meaning you can only really make out the shapes of the models and nothing more. Performance, you may have noticed is also really bad, significantly worse than almost all the other Sega ST-V titles, and surprising considering it’s “only” Saturn based hardware.

So why does Decathlete look so bad compared to all the other ST-V titles in every single MAME version up to and including 0.200? Simple, it had additional protection of a type that had not yet been figured out.

The ST-V cartridge for Decathlete contains a chip marked 315-5838, this chip provides encryption and compression related functions for the game, and figuring it out has been on my ToDo list for a long time, but the lack of decompressed and unencrypted data to study was a problem. To compound the problem the game data did not fully align with that found in the home port to the Sega Saturn either, so that wasn’t especially helpful as a source of unencrypted data to study.

Since Peter Wilhelmsen and Morten Shearman Kirkegaard have been working with me and producing hardware solutions to get data out of systems this seemed like a decent target for them to help with as a solution to easily transfer the decompressed and decrypted data from the game to a PC would provide significantly more data to study. I helped by providing information about the way the device works in terms of the SH2 program using it, where the encrypted data was, and my own observations on the tables uploaded (one of them clearly being a dictionary etc.) while Peter and Morten went to work producing a piece of hardware that slots in where the main program ROM would go on an ST-V cartridge, allowing us to sniff bus accesses to the ROM space as a way of transferring any data the SH2s can see back to the PC; the same technique that was used to transfer data back from the PGM2 unit and one we hope to use with some other systems like Casio Loopy in the future. This is much easier and more efficient than trying to display the data onscreen or anything like that.

With these tools and a list of source data provided they were able to extract all the decrypted and decompressed data from the game. I verified the extracted data by hacking up the protection device emulation to allowing MAME to read data directly from the files provided by Peter and Morten, and could confirm that for the files I hooked up the graphics appeared correctly in the game.

This was not the end of things however as supporting the data in decrypted form would not be true emulation, the real algorithm was needed and because this chip provided compression functions as well as the encryption there was an extra hurdle in the way (pun intended)

Anyway, Morten actually ended up making quite short work of this, using the tables uploaded by the game at runtime to figure out the nature of the compression, and writing a program that could recompress the extracted (fully decompressed / decrypted) data giving compressed (but not encrypted) blocks of data that were the same size as the compressed (but encrypted) blocks of data in the original game rom.

Since we now had the compressed, but unencrypted form of the compressed, encrypted data found in the ROM the encryption scheme could be studied too. We were hoping that it would be a simple 16-bit XOR that changed per-game, but instead, while still operating on 16-bits, it turned out to be more complex. Morten & Peter did figure out something that worked, and could correctly decrypt the data, but it wasn’t the cleanest of algorithms. Samuel Neves stepped in at this point and helped try to simplify the algorithm as much as possible, but even after that it was still a lot more complex than a simple XOR. This is actually quite frustrating, because while none are as high-profile as Decathlete there are a number of other games using the same chip that clearly have different encryption keys and we’ll likely need study those too rather than being able to work it out from the data.

Anyway, I was provided with sample code by Peter and Morten which worked outside of MAME, and so I took on the task of adapting said code for use in MAME, ensuring it worked in a ‘stream in, stream out’ ‘bytes on request’ mode as required for it to work in the way the SH2s talking to it expect it to work. By hooking it up in MAME the graphics are now correctly decrypted when running the game.

As you can see the emulation isn’t perfect yet, but none of those problems are protection related anymore, merely video emulation glitches. A lot of things are transparent that shouldn’t be transparent, and for reasons not investigated performance of this is actually worse than some of the Naomi titles, despite being on Saturn hardware, it runs at about 30% ingame without frameskip. It’s probably a worst-case scenario for a fair bit of the MAME Saturn emulation code, which will need revisiting at some point. Due to these issues I’ve actually left it as ‘NOT WORKING’ for now, despite being playable, but I don’t want people to get a bad first impression of the improvements. This might change if other people feel it should be marked as working.

I mentioned other games using the chip, and those are

Name Club v1 and v2 (chip has a 317-0229 sticker):
These use it for compressing and encrypting the higher resolution image data that gets sent to the printer (so you can’t actually see any onscreen problems as a result of the missing emulation, but if we were to hook up printer emulation it would print out garbage)

Print Club Winnie The Pooh Vol 2 / 3 (chip has a 317-0230 sticker):
Uses it to decrypt a block of startup code, so the machine doesn’t boot right now. Use beyond that unconfirmed, might just be that one block of data.

Print Club Love Love Vol 1 / 2 (chip has a 317-0231 sticker):
Same use as other PC Winnie The Pooh

Dead or Alive (on Model 2A)
Game uses it to decrypt a single string, which it then does a byte-for-byte comparison against the expected result. This has been hacked around for long before people even knew it had this complex decryption / compression chip, an absolute waste of silicon.

The other cases are potentially going to be annoying as they’ll require work to give us enough data to figure out the encryption part. Dead of Alive for example, we have the exact output string, and the compressed / encrypted data, and can even recompress the string, but there’s not enough data there to actually draw any conclusions about the encryption part.

Could there be more, maybe, there are a lot of random redemption games and a ton of undiscovered Print Club cartridges still out there.

Here’s a video of Decathlete running, note this was recorded with -aviwrite, so appears to be full speed even when the emulation was running much slower.

Content not available.
Please allow cookies by clicking Accept on the banner

Other slightly interesting notes about Decathlete, depending on the BIOS region it uses different compressed data for some elements. The US region is obvious, the Winners Don’t Use Drugs logo isn’t needed for other regions, so doesn’t get decompressed. What is less obvious is why it uses slightly different font data, I haven’t studied it much, but the difference in size isn’t enough to cover Japanese characters or the like. This actually confused me at first because Peter and Morten were working with an STV unit that had a European bios, and all my notes were based off running it in Japanese.