General News

The IGS027A chips are meant to be scary boxes of hell, and in most cases they are.

** If used correctly **

I was looking at Demon Front and noticed something odd. Unlike ‘The Gladiator’ and most of the other later type games the code in the external ARM rom makes no reference to the internal ROM space. There are no obvious jumps back to the internal code area anywhere.

So I did a quick mod, wrote some fake ARM code to set up the stack pointer and then jump straight to the external area, and this happened.

Now while I can’t guarantee this is perfectly emulated because it’s possible the internal ARM code should be setting up some more things before jumping to the external code it’s still a huge surprise, and looks like a massive oversight when the game was developed. I guess the biggest surprise is that it’s taken until now to notice, it’s literally an 8-word patch.

My only theory is that maybe if this is the first game with an ‘Execute Only’ area IGS wanted to contain all the internal code in that area to make it more secure, but it has the opposite effect. I guess I should probe it a bit to see if there is anything interesting there at all.

‘Fantastic’ and ‘Kong’ both of which featured in my previous WIP update here were cheap Brazilian produced rip-offs of classic games which made use of graphics from the original games but were completely reprogrammed from scratch leaving them with a feel very different from the games they aspired to be.

It’s therefore somewhat appropriate that the current update is about a game with similar traits, albeit it officially licensed this time around.

First, let’s look at three games which the current versions of MAME support:

Yep, the iconic DonPachi, and it’s sequels DoDonPachi and DoDonPachi Dai-Ou-Jou. 3 games produced by well known ‘bullet-hell’ shooter manufacturer Cave with the latter being released on a single board variant of the IGS produced PGM platform.

Now let’s look at another game:

DoDonPachi 2, note how the game only displays ‘licensed by Cave’ (and only even displays that in the Japanese version)

DoDonPachi 2, or Bee Storm as it’s otherwise known is a pseudo-sequel to DoDonPachi, but it was developed & published entirely by IGS, not by Cave. Like many IGS games it also suffers from a complete lack of ports, essentially a situation I call ‘PCB-locked’ and because the game wasn’t made by Cave, and appears to have been completely disowned by Cave as well many fans of the series in a similar way to how Nintendo disown the CD-i Zelda and Mario titles, it would seem an official port of this game is unlikely to ever happen.

I can only assume the game was produced as part of the deal which would later see Cave make use of the PGM hardware in single board form for what were arguably their best 3 releases, EspGaluda, Ketsui and Dai-Ou-Jou.

The game certainly looks like a Cave title, but that’s because the majority of the graphics have been recycled from DoDonPachi with minor adjustments (which is also a shame the PGM board is capable of much better visuals, as Cave themselves showed later) the real problem is it doesn’t play like one and there are threads all over the place which pull apart exactly how the game differs from a proper Cave title, everything from scores not resetting on continue, to bees having no special meaning, bosses having no energy bars, lack of score based extends, and a completely different scoring / chaining / bullet ‘buzzing’ mechanic.

That doesn’t mean it’s a bad game. It could possibly be considered the most accessible game in the series, IGS went to great trouble to localize it as was done for many PGM games, which makes the lack of ports seem even stranger; it’s also considered easier, with a practice mode for beginners. The real problem is if you’ve already played DoDonPachi there isn’t a lot new to see, and the execution simply isn’t as polished as the original game. As a game it’s not terrible but the DoDonPachi name gives a burden of expectation which simply isn’t met.

Until now DoDonPachi 2 wasn’t working in MAME which surprised a lot of people because the official Cave titles on PGM hardware have been working for a while now. Obviously the main point of this update is to show that progress has been made on the emulation of the game, and it is now functional.

Most mid-late PGM titles have additional sub-cpus, used as either protection, or to boost the power of the system. Some games make very weak use of these CPUs, which was the case with the 3 Cave titles, simulating the expected behaviour was trivial. DoDonPachi 2 on the other hand, being produced by IGS instead of Cave makes extensive use of the extra CPU for many critical tasks during gameplay, the only way to emulate the games is to emulate the sub CPU.

For the mid-late released games this was a fast ARM based CPU with internal and external ROM data. To properly emulate any of these PGM games the internal ROM has to be dumped out which is easier said than done, especially for anything produced after 2002 where the data seems to be fully secured against reading. Luckily DoDonPachi 2 uses one of the earlier chips and with a bit of trickery could be read out.

The result of running the game in MAME with the sub-cpu emulated can be seen in the video below. The board used was a Japanese board, and the Internal ROM supplies the region data, so without any hacks it runs as the Japanese version. Sound doesn’t seem very good right now, but that’s probably the ICS emulation.

thanks to ‘rtw’ for working with me on getting this one up and running. For reference, without the ARM emulated no bullets ever spawn, the options on your ship don’t work correctly, there are no medals, and your ship vanishes entirely after the first level eventually leaving the game unplayable.

Some additional screenshots of the game running properly:

Note this will NOT help with the following games which have fully secured areas in their internal ROMs. Don’t ask about them
Demon Front, The Gladiator – Road of the Sword / Shen Jian, Oriental Legend Special/Super Plus, The Killing Blade Plus/EX, Happy 6-in-1, S.V.G. – Spectral vs Generation

Taito do Brazil (the Brazilian Taito division) seem to have been something of an oddity. While no official Japanese release of Taito games contained any strings relating to the Brazil they would import games, modify them, and occasional write their own using what hardware they had available. Effectively they worked completely independently of the rest of Taito.

Some of their output appears to be little more than bootleg quality (hacked strings) while other work is more interesting. I don’t know how much Taito actually knew about when it came to their Brazlian operations, but I suspect not much.

Previously a game called “Galactica – Batalha Espacial” was emulated, this was a remake of Galaxian on Space Invaders hardware. Attempting to go one better it appears they also remade Galaga and released it on Galaxian hardware (technically Moon Cresta, but they’re so close it doesn’t matter) For whatever reason they decided to call their creation ‘Fantastic’

So far I’ve managed to get it into test mode. The rom has a slight block scramble to it, making things annoying.

Given that the board also has issues (See YouTube video) I’m having to cross my fingers that the ROMs are actually good although I see no obvious signs to indicate otherwise just yet, however I’m not convinced the PROM is a good dump because using a standard Moon Cresta / Galaxian decode you get a bunch of pastel colours.

Note, I don’t actually see any Taito strings in the ROM or graphics, but they could be non-ascii encoded.

*edit* got it ingame, bit glitchy tho, and unplayable, probably the rom descramble isn’t quite right

*edit2* fixed some of the rom scrambling, enemy formations are now correct. gfx banking is wrong, sound is wrong, star scrolling is wrong, bullets are wrong but you can now move about and shoot things. I think some of the wiremods on the board make it act more like a Galaga board than a Moon Cresta / Galaxian one.

thanks to Augusto Garcia, Silvio Finotti & Marcello Mancini for sourcing + dumping this one.

If previous recent years are anything to go by we’ve probably seen the early year flurry of activity MAME gets towards the end of December through to February. So a summary of the major things.

CHD Changes

Some simple CHD changes to add FLAC for Audio ended up turning into a complete rewrite of the format. The FLAC support is there, now, as is LZMA support in CHDs, although the latter gives disappointing results compared to when it’s applied to standard ZIPs. There probably is room for further improvement with the compression of data tracks on CDs because generally you can calculate error correction information and check it matches the source data you have instead of storing it (except in cases where it’s intentionally wrong for copy protection purposes in which case you’d have to store it) but that depends on the sector format and other things, so probably won’t be done especially as other recent changes have already made compression many times slower. As it stands there are decent gains on a set of MESS CHDs, less so for a MAME set, although the savings on the Beatmania CHDs aren’t shabby at all.

Unfortunately as part of the process the SHA1s for CHDs with older style metadata did change, although this only really affects MAME because all the CHDs supported in MESS were created with newer CHDMAN versions which already had the newer style metadata. This is something of an inconvenience and means ~200 SHA1s will need updating in MAME, forcing people to use V5 if they want to avoid SHA1 error reports. This is a shame because ideally I wanted the changes to be entirely optional so that people could simply stick with V4 if it suited them better but Aaron clearly had different ideas and wanted to ditch the legacy metadata.

There are still some outstanding bugs with the new tools at the time of writing, which I hope get ironed out before a proper release hits. Of note:

1. Converting a CD CHD with ‘chdman copy’ will NOT update the default hunksize to a larger one, which is optimal in more cases. To do that you’ll have to manually extract and re-create the CHD, be warned tho, certain CHDs won’t extract to .cue/.bin because they contain data the format is incapable of representing. Minor issue, but one to be aware of. It’s quite easy to hack up your own CHDMAN build to automatically force the correct hunk size when updating a CD.

2. Laserdisc CHDs (the big ones) aren’t safe to convert yet. The metadata in them is changing for unknown reasons, and decompression fails (although bypassing the code where it fails seems to result in a correctly output file?) This is a major issue, be careful.

3. GD-ROMs might not be safe to convert. R.Belmont says the old code worked more by chance, and had bugs. This is also potentially a major issue

4. Random hangs when converting. For some reason CHDMAN sometimes hangs when converting HDD CHDs, this appears to be random, possibly a thread safety issue. This almost certainly makes it unsafe for reading real drives to a CHD file. Again I’d consider this a potentially major issue, although it won’t affect you if you’re just using MAME.

I’d also probably add a ‘fast’ preset option for reading actual drives, which only uses the basic compression schemes. If you’re reading a drive you don’t want to be sitting around 20x longer than you need to while it finds the best compression, you can do that later as part of an off-line process.

7Zip Support

Romsets, Artwork, Cheat Files, Samples etc. can now be stored in .7z archives rather than plain zips. This gives compression advantages, and as long as you’re sensible about the compression options doesn’t incur too much additional memory / processor overhead when loading.

The implementation is currently tested and working for most use cases, and I’ve yet to see any bug reports for it (which to be honest surprises me) It’s beneficial for things like the cheat XMLs where you can use 7z to compress them down to a nice neat 600kb file with almost no noticeable loading delay!

The -romident function of MAME is also hooked up to handle .7z files, however romcmp.exe isn’t yet (shouldn’t be too hard) I’m also told that loading MESS software directly rather than via the software lists requires a bit of extra code, probably something as simple as it not seeing a .7z as a rom extension.

FLAC Sample Support

Your samples can also be encoded with FLAC if you desire, and while this was initially used as a testbed for the format support before adding it to the CHD spec you might find it handy. The APE support was never added (a shame, I think it’s a good to have as a demonstration for people to at least see why it isn’t the preferred method)

There should be no issues here at present.

Merged Builds

While the official teams still seem to have some inexplicable hangups over offering the source to build these, or the binaries themselves it’s pleasing to see that the code previously posted still works, and all the patches to resolve both compile and runtime errors with such builds have been accepted. I haven’t posted a build recently because I’m still waiting for the CHD changes to settle. I do still hope that one day this becomes the primary target, with the MAME/MESS individual builds offered for people who want ‘stripped down’ versions, but with the current teams I think it will be a cold day in hell before that ever happens. Power struggles would simply get in the way.

x86 Progress

The recent x86 progress is a good example of why MAME needs MESS. Contributions to the MESS side from ‘carl’ have made great strides with the x86 emulation in MESS, edging it closer to Dosbox in terms of compatibility, as opposed to before when nothing requiring protected mode would work at all. You can even install Windows 95 within MESS now, although it isn’t fully functional yet. MAME benefited a bit as well, a few x86 based games now do more, California Chase for example, although face it, nobody would have bothered to improve the x86 emulation to the level needed for that if it wasn’t for MESS and PC support ;-)

Fruit Machines

Fruit machine progress is slowly getting back into gear after the initial burnout, more sets have been split (mainly by J.Wallace) and I’m looking into the extras the various CPU cores need now. I know a lot of people seem to think these are things which can never work in MAME because they had no displays, but MAME already emulates several games without monitors (look at 30test, another recent addition, it doesn’t even look bad without artwork!) MESS also emulates a number of systems without real displays (Chess computers for example) I know it’s going to be hard to live up to big expectations with these, but they will get there, eventually. Mooglyguy has also expressed an interest in rewriting MAME’s presentation layer, which is of great interest when it comes to these machines which are going to depend heavily on good looking light simulations when artwork is used. It also needs it, the current artwork code is IMHO horrible.

3D Systems progress

Ville has been active again, and submitted updates for a number of 3D systems in MAME, improving the graphics in GTI Club for example. Mooglyguy has also been working on N64 MESS side trying to squeeze a bit more performance out of the drivers. This has had benefits MAME side with a number of Aleck64 games now booting and/or running faster. Sadly for a lot of these systems things are still out of the performance envelope for current PCs and considering we’re at least 10-20x slower than things like Demul, which is already getting a public roasting for being too slow because you require a modest PC to get 60fps on Dreamcast games and lacking artificial enhancements I have a feeling that 3d in MAME is never going to be well received or accepted.

Deco Cassettes

As shown on the previous updates here there has been a fair amount of progress with Deco Cassettes, and they can once again be dumped safely, although all that needs saying has been said already :-) Probably the highlight of the last few months this one.

New games / clones

Not a great deal to write home about here. A couple of new Korean games showed up and were working, including the now legendary Boonga Boonga / Spank ‘Em although from an emulation point of view that isn’t very interesting, just running on an already emulated Hyperstone platform. Gameplay wise it isn’t very interesting either, it’s not much more than a gambling game where you can win medals at the discretion of the machine. 2 Semicom titles were added, and while I’m usually enthusiastic about these both are very generic, and not too interesting. There was Toyland Adventure, which is a ‘clear the screen’ game in the vein of Tumble Pop etc. but offers nothing new in terms of gameplay while suffering from frustrating controls and slow-paced action. There’s also Diet Family, which is a Galaga style shooter on ‘cute’ scrolling backgrounds but also lacks any distinguishing features or polish. Compared to their other Hyperstone titles such as Wyvern Wings and Mr. Kicker these are both very poor efforts.

Some clones showed up, the most recent revisions of the 2 Jojo games on CPS3 are now supported (although the most recent revisions of the first 2 Street Fighter 3 games still remain unsourced)

The unlicensed NeoGeo title ‘Super Bubble Pop’ was added, but controls for P1 are non-functional (possibly protection, although Player 2 controls work fine) Game seems to be rather buggy, so might just be bad code which out emulation is sensitive to.

A whole bunch of non-working sets were also added, but with no devs showing a real interest in actually emulating these things, combined with them being relatively modern systems I can’t really see those additions coming to much.

Under the hood Changes

Aaron rewrote a whole bunch of core code as usual, end-user benefits are non-existent tho, so not much to write about here. From a code perspective things probably became a bit more complex, requiring extra attention to be paid to bitmap modes and such but assuming there are no remaining bugs there’s nothing a regular end user should notice from any of these changes. (Some people have reported less lag in the odd shooter, but I have a feeling this is more to do with games getting slightly broken due to adjusted timings, and sprites no longer buffering at the same point in time)

Lots of rom renaming, documentation fixes, things like that.. Kale stripped out the remaining deprecat.h usage in December (although I believe one or two things are still broken from that)

Other Stuff?

I optimized the PGM video code a bit, Sliver uses libJpeg to decode it’s bitmaps, and a couple of minor changes were made here and there. The last few days have seen preliminary Votrax support from OG/LN etc. go in which will eventually be used for Gorf etc. (not yet anywhere near the quality of distinguishable speech, so disabled) I also finished off converting some Data East drivers to use the sprite devices I added, adding support for bootleg variations at the same time, but that’s nothing really significant.

But… that’s about it off the top of my head, no decap news on the more interesting targets (Taito C-Chip, Toaplan sound MCUs) (actually no decap news at all) No progress on things like System 10 (which surprises me) No progress on Seibu (which surprises me less) Very little in the realm of long term broken games being fixed. No improvements to discrete emulation / games getting discrete sound systems emulated which is usually something done in the Winter months. I’m probably as guilty as anybody for spending the last 3 months focusing on tasks not directly related to the emulation (the 7-zip for example) but it remains worrying / disappointing especially in what is traditionally quite a busy period.

On the MESS / Console side Byuu is on the verge or emulating the final SNES co-processor after extracting the ROM from it (which would be a landmark achievement) but aside the recent x86 progress it’s been unusually quiet there too, some 68k fixes for the ‘NExT’ emulation and some obscure systems booting, and the previously mentioned N64 improvements but otherwise very little progress on the staple systems, although I do hope to resolve that by adding NeoGeo CD support sometime soon. At least with MESS there is a clear steady flow of improvements to drivers, old and new and the 3rd party contributions are encouraging showing a willingness to tackle difficult tasks like the x86 emulation head-on unlike MAME where even simple drivers seem to be left untouched with people almost afraid to even try when it comes to making progress.

Hopefully this year won’t see a dramatic drop-off of interesting contributions after this Winter period as has happened some years, because if it does we’re likely to be faced with nearly no development occurring at all.

Remember these projects are the result of hundreds of thousands hours work by people, all done for free. Continued code contributions ARE needed to keep it going. Don’t be selfish by assuming somebody else will do the work just because your favorite systems / games are already emulated, or it doesn’t matter because there is another emulator already doing a better job. If I’d taken that attitude you probably wouldn’t have the likes of CPS3….

Aaron has checked in a change to the CHD format featuring his further work on the format, and bumping the version to v5.

This includes a refined / cleaned up version of the FLAC support I was working on (which is now official) as well as a number of other improvements (LZMA support based on the 7-zip code is also in there)

I haven’t tested / used this code yet, so I can’t say how compressions compare (if data is being optimally ordered for FLAC etc.) but you should see substantial gains, even over the previous versions I posted due to the use of LZMA which in tests on regular romsets usually yields around a 20% improvement in compression. The LZMA improvements mean there will also be benefits to non-CD CHDs. LD ones are also likely to shrink very slightly as FLAC is being used for the audio part of those now (don’t expect big savings tho, they’ve always been video-heavy and lossless video compression is always going to give big files)

The created CD CHDs are SHA1-compatible with the previous ones, so none of the software lists need updating thankfully.

Just a heads up, because unless there are any bugs this will be the expected version from the next release, as opposed to the previous FLAC trial runs.

In case you haven’t been following any of this here’s a summary:
Old V4 (and below) CHD format used ‘zip’ compression internally.
New V5 format supports ‘zip’ , ‘lzma’ (7-zip) and ‘flac’

FLAC seems to give about 40% better compression than ‘zip’ for audio data (CD AUDIO tracks)
LZMA seems to give about 20% better compression than ‘zip’ on regular data.

Of course some data just plain doesn’t compress well, so you’re not going to see those saving everywhere but you’re likely to see on average a 20-40% reduction in CHD size for all non Laserdisc CHDs.

This naturally makes CHD better for storing large amounts of data, which was it’s original purpose.

As it transpires the release of MAME 0.145 was meant to come with a ‘promo’ combined MAME / MESS build, at least that was the plan at one stage. Why that didn’t happen I don’t know. Maybe concerns about the overall stability of the 0.145 release giving a bad impression, maybe a lack of time, maybe some more boxes needing to be ticked with various devs, maybe some last minute conflicts which prevented it going ahead. Either way, it didn’t happen.

Anyhow, there was some *official* code written for this purpose, similar to the last Ultimate patch I posted, but stripped down a bit further to the bare minimum of changes needed to build it. The code, written by Micko (MESS Co-ordinator) has been given to me, and I’ve uploaded it here. That code builds a variant called ‘universal.exe’ / ‘universal64.exe’. Given that it was the plan to include it at one point I’m cautiously optimistic that this may yet see the light of day in the official source trees (and maybe even as binaries) but we’ll see.

Personally I find ‘universal.exe’ a bit of a mouthful, so in building a new EXE myself I’ve shortened that to simply ‘uni.exe and ‘uni64.exe’ (UNIversal emulator).. actually UNE (UNiversal Emulator) would would also be a reasonable executable name. But, minor detail, this combined build has yet to really be given a proper name, so for now I’m still just gong to call it ‘Ultimate MAME’

Ultimate MAME 0.145+ (MESS SVN r14446) (GIT rev)

This as suggested is built from the MESS SVN r14446 code. It includes everything from the MAME/MESS of that revision, including the 7-zip support for ROMs.

As an additional option I’ve included extra binaries which are built as ‘MESS’. Those binaries will identify themselves as ‘MESS’ to external applications instead of Ultimate/Universal/MAME. This is done for compatibility with the QMC2 frontend. The MESS Version of the QMC2 frontend can be used with the ‘MESS’ binaries, because as far as it’s concerned it’s just a build of MESS with additional arcade titles. The actual MAME version of QMC2 is more stripped down and lacking in features needed to run various systems included in the Ultimate version, so you have to trick it into thinking it’s running MESS. If you’re not running / wanting to run QMC2 you have no need for these binaries.

EASY WAY, FOR THE LAZY

64-bit link (RAR) (includes resources, source, 64-bit uni.exe binary, and a 64-bit all-inclusive binary built as mess.exe instead for if you want to use QMC2)
32-bit link (RAR) (same as above, but 32-bit)

MANUAL WAY, FOR THE TECHNICAL

the following patches were used
Universal / Ultimate MAME build target
Patch to resolve build conflict with ‘bullet’ (name was used for both Wave Mate Bullet in MESS and Sega’s Bullet in MAME)
APE support patch for Samples (not vital but you can play with it if you want, see prior update for details)

SVN r14446 Common MAME/MESS Resource Files YOU WILL NEED THIS FOR ANY OF THE BINARIES / SOURCES BELOW TO WORK CORRECTLY (it includes the softlists, and artwork used by a number of MESS Systems)
Source code for builds below (patches pre applied)
64-bit Binaries (with tools) (drop these in the folder where you extract the above resources)
32-bit Binaries (with tools) (or these if you’re on 32-bit)
64-bit Binaries (with tools) (built as MESS)
32-bit Binaries (with tools) (built as MESS)
(note, to build like the above 2 just copy mess.c (from /mess) over uni.c (in /uni) renaming it to uni.c, obviously)

—-

Due to the change in build process (using the Official patch instead of my own) there is a slight chance that some things might not behave quite as before, for example in my own builds I was making sure that the same CPU cores were built by each project, although with the modern MAME architecture it looks like such concerns were unnecessary (it used to be if you changed the CPU cores included you had to do a full recompile) Everything here is built first by building MESS (make) then building the Ultimate / Universal build using that as a base (make TARGET=uni) Finally tools were built (make tools)

—-

I usually provide a demo of some of the cool stuff / comparisons when I post one of these builds, but I haven’t really had much time to do anything like that with adding the various 7-zip, FLAC, APE and JPEG support as shown in prior posts. I’ll try and find something worth showing in the coming days tho, there is a lot of neat stuff happening in MESS lately such as the ability to run old versions of MAME on the 486 driver, but it doesn’t make for much in the way of screenshots, and it is a little slow to be of practical use regardless of the ‘cool’ factor it has :-) ..