Archive for January, 2015

UME is the complete/combined version of the MAME / MESS project.

Official whatsnew texts for (MAME, MESS) provide full details of what has changed since 0.157.

This is based on the official ‘mame0158’ tagged version at GitHub.

UME 0.158 Windows binaries – 32-bit, 64-bit and all tools
(source matches official mamedev.org source distribution, here for completeness)

Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.158 Windows binaries – 32-bit, 64-bit and all tools

Windows SDL builds
32-bit SDL MAME / MESS / UME for Windows
64-bit SDL MAME / MESS / UME for Windows

Points of Interest

0.158 represents steady progress in the right direction, all of the recent progress you’ve seen here is included, and a couple of things that I’ve not covered too, including what seems to be a rare original Italian game called ‘Star Trek’ running on Head On hardware) I’m inclined to think it should have a thruster sound instead of the car skid sound from Head On tho ;-) It’s not a game you’re going to lose sleep over playing, but does appear to be a very rare find!

There are some important little bugfixes in there too, things like the fix for the Space Harrier MCU simulation (it was doing the very subtle job of setting some bonus lives flags, not easy to catch) and priorities on one of the Batrider bosses (although if anybody notices any new priority bugs in the Toaplan 2 driver with 0.158 please do let me know) Super Punch Out also had an annoying reset ug in 0.157 due to premature removal of some protection workarounds, that’s fixed too. Work was also done on the -mt flag to fix a number of palette glitches that occured when using it, while I haven’t tested it extensively it might be safe to use once again for a fractional performance gain. (unless you have really bad video card drivers that are dog slow in even doing a simple blit, in which case the gain is more noticable) A number of Windows specific issues were also fixed in the SDL builds, which is why I’m offering those again for this release, more on that later tho.

Tetris heads will be happy to know that TGM2 is now set to the correct ~61.7 refresh rate, rather than the incorrect ’60’, meaning that timing should now properly match the PCB, even if that means the ingame timer is no longer counting real seconds (it assumes 60fps)

About SDLMAME/MESS/UME

If you’re running MAME on Windows XP using a nVidia card then you might be familiar with the instant Blue Screen of Death (or just instant machine reboot) you get when running MAME with any drivers nVidia from the last 5+ years. This is due to a bug in the nVidia drivers that happens to be triggered by MAME. We’re not doing anything illegal, or even fancy, we’re just unfortunate enough to get caught by it. nVidia have confirmed that they’re not going to fix it because it only affect unsupported Operating Systems and we and unsupported cards, and w can’t really fix it because it’s basically impossible to debug, so the only remedy for this using regular MAME is to either use the Software / DirectDraw renderer (-video ddraw) or stick with very old nVidia drivers.

If you want to avoid that problem then the SDL builds could be useful to you. For an accelerated mode they use ‘OpenGL’ instead of D3D and appear unaffected by the nVidia bug, meaning no BSODs on launch even if you use the latest drivers. I’m offering SDL builds for 0.158 because some important Windows specific bugs in the port were fixed over the course of the 0.157 -> 0.158 cycle.

The SDL builds also use GLSL shaders instead of HLSL, they can be a little tricky to get working (and there’s no Vector shader support) but a number of people have found they prefer the results over the HLSL approach (it’s personal preference) and there are shaders available that might actually be more suitable for lower end hardware.

You might also want to consider the SDLMAME builds if you’re running an Intel graphics based system and simply getting a black screen with MAME, or random error messages on startup telling you that D3D couldn’t be initialized. I’ve noticed this happening quite a lot even on Windows 8 laptops with Intel HD chipsets, older ones seem even worse. I haven’t checked if it does fix the ‘black screen’ problem with older Intel chipsets, but as it’s a completely different codepath it’s worth a try.

If you’re on XP + nVidia and would rather just go the ‘older drivers’ route, I’m told ‘258.96‘ from 2010 work with the regular versions of MAME we post. Some people have said the issue affects Vista users too, although there aren’t many of those left ;-)

There were 3 other Model 3 games with encrypted graphics, Metallic found the keys for those, and the graphics have now been decrypted.

Note, not all of these run well in MAME for other reasons.

LA Machineguns had an encrypted title screen and encrypted HUD graphics. The game still runs in slow motion in MAME tho (even if you were to speed it up to 100%) I guess interrupt issues or similar.

Virtual On 2 had various encrypted 2D graphics (insert coin text, player / enemy status during gameplay, various target graphics) MAME still has issues with bad textures on the robots due to missing features of the 3D emulation (not encryption related) Also controls aren’t set up correctly afaik.

Magical Truck Adventure also had encrypted 2D graphics for insert coin etc. and some ingame status graphics. There are still some game logic bugs in MAME (it seems impossible to avoid obstacles even if you select the right direction and the controls aren’t fully mapped) Also it glitches out and loses 3D graphics if you leave it in attract mode for long enough (see last shot) probably a CPU core bug.

After hooking up the 315-5881 encryption/compression emulation to Model 3 I collected some data from Dirt Devils and sent it to Metallic in order for him to search for a key. He found one, and now the HUD graphics (text etc. on the screen) get correctly decrypted and decompressed – something which is currently lacking in the ‘SuperModel’ emulator. Here are some shots of Dirt Devils running in MAME with the text layer working.

As this is MAME, and this is a ‘modern’ 3D game it doesn’t really run too well on my hardware (although I’ve heard it’s not so bad on an i7) so fingers crossed this brings the SuperModel team back to life and they backport some of this work.

The other ST-V game that really, really needed a working decryption emulation was Touryuu Densetsu Elan-Doree / Elan Doree – Legend of Dragoon, where most of the textures were encrypted.

Metallic used the same approach he used to get the Final Fight Revenge key to obtain the key for Elan Doree as well as the ones for the other ST-V games (Steep Slope Sliders, Radiant Silvergun – both of which already had working simulations but now use proper emulation)

Again there are graphical issues and performance problems still, but that’s due to our Saturn / ST-V emulation, especially noticeable because this runs in a high resolution.

I also hooked up the encryption device to the Model 2 driver (Dynamite Cop) and Model 3 driver (Star Wars Trilogy) allowing our existing simulation code to be replaced there (it returns text strings, so the simulation was already returning the correct data, meaning no visible improvement, just more correct to hardware code)

Using the new knowledge (and ST-V hookup for the encryption) talked about in the previous post Metallic was able to brute force a key for Capcom’s “Final Fight Revenge” allowing it to boot.

It’s slow and glitchy (but no surprise, the Saturn version in MESS is too, so I don’t think the issues are caused by bad decryption) and definitely one of Capcom’s weaker efforts but it’s nice to finally have it running, it was previously the only ST-V game that didn’t boot at all because they encrypt the first few blocks of code meaning it couldn’t start up at all.

Hopefully we can improve the ST-V / Saturn emulation a bit sometime soon.

If you’ve been following recent news / various GIT commits then you might have noticed that we recent connected the dots between the encryption/compression schemes used on Naomi carts and those used on other Sega systems (ST-V, Model 2, Model 3) etc.

In many cases these were used as a simple protection (especially on Model 2 / 3 and Radiant Silvergun in STV) just writing some values, reading them back and comparing them against a string in the code (which is very easy to bypass) but the reality is that there is a chip performing rather complex decompression and decryption operations on the data written in order to get that result, and in some cases it was actually used properly!

It was discovered by ANY and others that many of these boards used a 315-5881 chip, we’d long suspected it could be the same scheme, but had never actually managed to make a firm connection. Software to extract data for analysis from a Naomi board already exists, and it turned out that by transplanting one of the chips from an ST-V cartridge onto a Naomi board we could use the existing extraction code and obtain a key thus confirming the chips were exactly the same thing just programmed with different keys.

The encryption implementation, as it turned out, was missing some important details, features that none of the Naomi games really used (multiple encrypted/compressed blocks in a stream with mid-stream headers, non-power of 2 sizes for compressed data etc.) furthermore our encryption implementation was incomplete, so Andreas needed to further study the data and fill in some gaps. I poked around with the multiple block side of things a little, and eventually we’ve ended up with this

previously both these graphics (the Tecmo logo and entire title screen) were displayed as garbage because they’re both compressed and encrypted. I do wonder if there aren’t still some flaws (the Tecmo logo looks rather rough) but it could be right (see next statement), and the title screen definitely looks fine. An interesting fact is that the game also checks a few values in the decompressed Tecmo logo and if they don’t match the expected return values then the game breaks in various ways, for example the ball / player movement.

If you’re curious, the Tecmo logo is a single compressed stream with one block of compressed data. The title screen is a single stream with 4 blocks of compressed data (one for each quarter of the screen)

Performance still isn’t great here (it’s a high resolution ST-V game, and our video rendering code is slow)

Astra Super Stars also benefited from this, previously we were handling the HUD layer by loading the HUD data from the Sega Saturn version as a fake ‘ROM’ file in the romset, with the decryption hooked up I was able to remove the fake rom, the resultant data from the decryption process is identical so there’s no visible change, just the knowledge that we’re no longer depending on data that wasn’t on the PCB. Astra Superstars was a bit of odd one really, for some reason the chip marked ‘315-5881 317-5040-COM’ was actually used by 3 games (the other 2 being ‘Shin Nihon Pro Wrestling Toukon Retsuden 4 Arcade Edition’ and ‘World Kicks’) meaning we already had a key from the previous work on Naomi.

Note, while this will help a number of ST-V games once we get the correct keys it WILL NOT help Decathlete because Decathlete uses an entirely different chip.

My next plan is to hook this up to Model 2 / Model 3 in MAME, it won’t really improve the MAME driver, but if we can extract / brute force an encryption key for Dirt Devils it should allow the SuperModel devs to fix the 2D layer (see here) if they decide to update the emulator again.