David Haywood's Homepage
MAME work and other stuff

In Brazil *Everything* is Fantastic

March 8, 2012 Haze Categories: General News. 58 Comments on In Brazil *Everything* is Fantastic

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

Fantastic Fantastic Fantastic

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

Fantastic Fantastic Fantastic Fantastic

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

Go to article.. »

Marching On

March 2, 2012 Haze Categories: General News. 11 Comments on 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….

Go to article.. »

CHD v5

February 16, 2012 Haze Categories: General News. 56 Comments on CHD v5

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.

Go to article.. »

Ultimately MIA

February 14, 2012 Haze Categories: General News. 26 Comments on Ultimately MIA

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.


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)


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 :-) ..

Go to article.. »

Ready Steady Deco

February 13, 2012 Haze Categories: General News. 19 Comments on Ready Steady Deco

Charles MacDonald has recently been posting information about the DECO Cassette system in order to get some more tapes dumped because there hasn’t really been any activity on them since way back when the initial batch was added.

This is good news because these things (being magnetic media and custom dongles) are extremely fragile, and the remaining ones REALLY need sourcing and dumping before it’s too late. Of course, all that work isn’t much good if there’s nothing to show for it, but luckily there is. Here is ‘The Grand Sumo’ one of the previously undumped DECO Cassettes. In the end it was a simple slot-in to the driver (Type 4 dongle, BIOS Type A) so I can’t really take credit for anything, but Charles’ fantastic work, and the contributors who have helped buy the game and equipment needed deserve a shout out here.

The Grand Sumo The Grand Sumo

AFAIK the Dumping Union *don’t* currently have access to the other rare games, and if they show up they’re bound to be pricey, so please consider donating to them if you want to help source these rare and fragile pieces of history.

One of the most important things to note about Charles’ work is it means the dumping is now a NON-DESTRUCTIVE process. The dongles are dumped without even opening them, so it’s risk free compared to older methods. This is good news for people who own the cassettes if they’re considering loaning them out.

Credit this time round goes to Charles MacDonald, Dr. Spankenstein, Kevin Eshbach, T. Huff, SteveS, E. Page-Hanify, Hikari, ArcadeDude, F. Bukor, N. Francfort, jmurjr, arcade-history.com, ThumB, Hurray Banana, Paratech, Xiaou2, Cornishdavey, A. Costin, M. Ponweiser, Tormod, Rambo, Smitdogg, The Dumping Union

Go to article.. »


February 11, 2012 Haze Categories: General News. 36 Comments on 7-Zip-a-Dee-Doo-Dah

As promised below I’ve put a bit of time into hooking up 7-zip support in MAME. This is a first pass, so there is still room for improvements (both to code quality, and potentially bug fixes)

The way I see it zip / 7z offer the following pros / cons

– Aging 32-bit format
– Can only hold 2gb of data (we’re hitting that limit in some cases)
– Only supports UTF-8 filenames
– Single, dated algorithm
+ low memory overhead

+ Modern 64-bit format
+ No practical limitation to filesizes
+ UTF16 support (debatable advantage)
+ newer more advanced algorithms
– higher memory overhead if ‘solid’ blocks are used

Zlib (.zip support) might be tried and tested, but it’s showing it’s age, it’s a format of the previous decade when FAT32 was the standard, and nobody had large files. .7z is newer and doesn’t have many of the inherent issues of an older format, although does still need some testing. Staying ahead of the game is always a good idea tho, better to be modern and be prepared.

Download the diff here. This has been sent to R.Belmont for portability checking and official inclusion. Right now this can be used for roms, artwork, samples, cheats etc. -romident and romcmp.exe aren’t hooked up to it yet, but that will come with time. As I said, this is first pass, and a demonstration it works.

I’ve tested this with a wide range of settings in the Windows 7-zip binary and haven’t managed to make a file which fails to decompress yet. Both 32-bit and 64-bit Windows MAME builds have been tested and as long as you’re sensible about block sizes and compression used speed / memory overhead is comparable to standard .zip (ie don’t use PPmd with huge block sizes on huge ROMs because that would just be stupid and can take a good 3 minutes to decompress kof2003.zip even with the official tools ;-)

I’m increasingly being sent .7z files when asked to look at things to work on in MAME as opposed to zips in days gone by. I’d attribute a lot of this to the decline of WinZip (they practically nuked their own business model) as well as the horrendous build-in Zip support Windows has, forcing people to look for alternatives. This means having .7z support makes MAME work easier as I don’t have to decompress / recompress everything just to check it out. Weigh that up with the limitations of the format and moving forward seems like a good idea. I’m also often sent .rar files (because people appear to have flocked to either 7-zip or WinRAR in equal numbers) but I need to do further investigation on the suitability of decompression code for those, there are a few strings attached because it’s not a ‘free’ format.

Of course, the original .zip support remains, .7z is just an option. There is no reason to rip out the long standing .zip support, merely supplement it with something more modern.

The other benefit of course is that the LMZA and LMZA2 algorithms will be in the MAME code for leverage elsewhere, and would be ideal for use in CHDs and such. Not done anything on that front tho because it’s not a priority, and the FLAC work is still pending cleanups and being officially turned on.

Go to article.. »

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.