Marching On

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….