UME 0.153ex1

UME (logo by JackC)
UME is the complete/combined version of the MAME / MESS project.

0.153ex1 is built from SVN revision 29720

UME 0.153ex1 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex1 sources

Here is the 0.153 to 0.153ex1 SVN log

Points of Interest

MAME 0.153 was buggy, use of the brightness / gamma settings in the 32-bit builds would cause BG colour issues in anything using the ‘black_pen’ feature of MAME, most notably many 80s classics like Galaga.

There were other problems also affecting Namco titles like Galaga, Pole Position etc. – uninitialized variables causing anything with the Namco customs of the era to randomly boot into service mode, or display the gameplay upside down etc.

Another problem was causing MAME to crash if loading 0 byte files, many sample sets you find have 0 byte files for dummy samples (eg. Gorf) and while having these dummy files isn’t recommended it wasn’t ideal behaviour for MAME to simply crash when they were present.

I do not know if there will be an official 0.154 build following shortly to fix these issues, but they’ve all been fixed in the SVN at this point, so I’ve decided to put out this ex1 build of UME as a public service. It also includes the fixes to allow the SC4 fruit machines to pass their init once again after the 68681 refactoring.

I believe some issues from 0.153 still remain (cheat finding doesn’t work) but I felt it a good idea to get this out there before further instabilities are introduced.

There are a lot of other refactoring changes in this build, as well as Kale’s WIP on Model 2, so I can’t guarantee nothing else is broken, but I felt having builds where the classics were known to be in a semi-broken state was not a good idea.

Note, a number of changes in the changelog mention the new menu system, this was backed out shortly before this build as it isn’t yet stable.


UME 0.153

UME (logo by JackC)
UME is the complete/combined version of the MAME / MESS project.

Here is a build of UME compiled from the official 0.153 sources

UME 0.153 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153 sources

Here is the 0.152ex4 to 0.153 SVN log

Points of Interest


What did the air ever do to you?

I do like it when rare clones of existing games turn up, some have proven to be more than just a little elusive over the years and the subject of this article is one such clone.

MAME has emulated the IREM title ‘Fire Barrel’ for a while now (with significant improvements a few years back) and if you’ve ever booted the game in MAME this Japan region warning and title screen will be a familiar sight.

Fire Barrel Fire Barrel

Fire Barrel is quite a rare game compared to some other Irem titles but even rarer is the export version of that game known as Air Assault. For many years one could be found at the Trocadero in London, but apart from that nobody had seen a trace of it. We knew it was an official version because the tiles for the ‘Air Assault’ title were present in the graphic roms, just unused.

System11 has been a good source of clones in the last year or so, dumping every board he comes in contact with and often uncovering previously unknown revisions of existing games (especially Korean ones where there is no real indication whether something is an alt version until you’ve dumped the roms).

Anyway, to cut the story short one of his new arrivals was Air Assault, the very same Air Assault board that has been sitting in London for years. It looks like it might have been a location test version based on the ROM labels, although I think the code is actually a newer revision than the Japan set.

Luckily he got the board just in time, he’s also put up a strongly worded warning about a leaking capacitor problem that he’s witnessed plaguing these IREM boards, with this one already showing the first signs of that.

Getting this working in MAME wasn’t entirely straightforward, it uses a different encrypted sound CPU when compared to Fire Barrel, in this case the same as Gunforce rather than the same as R-Type Leo, however, there were some gaps in the encryption table causing the sound code to not run correctly and report a ROM error although I managed to fix them by using the code from the correctly decrypted set as a reference.

So here are some screenshots of Air Assault running in MAME, possibly salvaged from the only remaining board in existence. It might ‘only’ be a clone, but it’s one I’m very glad to see dumped.

Air Assault Air Assault Air Assault


UME 0.152ex4

UME (logo by JackC)
UME is the complete/combined version of the MAME / MESS project.

I feel the project has reached a relative level of stability compared to at other points over the last month so I’ve decided to put out an ‘ex4′ build of UME. There are still some outstanding issues that will likely need to be fixed before a real 0.153 build can be released (for example the breakage of all the Scorpion 4 fruit machine drivers) but overall we’re starting to look in better shape here than we have for a while.

0.152ex4 is based on SVN revision 28774

The changelog (simply a copy/paste of the SVN log) can be read here. This isn’t formatted as a whatsnew, but as usual I’ll summarize the main points below.

UME 0.152ex4 Windows binaries – 32-bit, 64-bit and all tools
UME 0.152ex4 sources

I’ve also decided to compile MAME / MESS builds for this in addition to the regular combined binary.
0.152ex4 (split binaries)

Points of Interest

I’ll write something if / when I find the time.

The build does contain the latest progress on Mega Phoenix and while emulation is still imperfect (some flickery graphics and bad sound) it does now seem to be playable

Most of the progress over the last few weeks has been internal however, as mentioned in the previous update here.


Current MAME Stability

If you’ve been following the MAME SVN you’ll have seen there have been a large number of changes being made as of late, refactoring of critical systems layered on top of previous refactoring of other critical systems.

If you’ve tried running a build built from the current code you’ll also have noticed that things aren’t especially stable right now, that is to be expected given the nature of the changes that are taking place.

When everything is done these changes should result in no user visible difference, but while they’re ongoing they are rather disruptive, that is why you haven’t seen a release, either official (0.153) or unofficial (one of my ‘ex’ builds) in a while; the previous release I did was right before some of the bigger changes hit.

This also means that actual progress is slow right now, it’s not easy to keep up to date with a project and do development when fundamental things about how MAME works are changing beneath your feet. It’s no excuse for me not fleshing out the text to go with the previous ‘ex’ update, but it does mean I’ve spent less time with MAME than I normally would.

Anyway, to make this a worthwhile update I should mention that one or two fairly interesting clones turned up over the past few days, for example a ‘Growing Ship’ version of Galaxian made by ‘Recreativos Franco’ of Spain was added. This version is unique in that it has 3 different player ship sizes and gives the player a bigger ship ever 2 levels. This is used to make the game more difficult. Thanks go to Roselson from AUMAP for this one, it comes from his PCB.

Recreativos Franco Galaxian Growing Ship Recreativos Franco Galaxian Growing Ship Recreativos Franco Galaxian Growing Ship Recreativos Franco Galaxian Growing Ship

An alt version of Poke Champ was picked up by system11 after I noticed it on eBay. This one is called Billard List and has a different selection if images (actual Photographs) The PCB also allowed us to correct the CPU clocks in MAME to reflect how badly the game runs on real hardware; it’s a hack of the Pocket Gal code, but actually has worse CPUs than Pocket Gal! Below are some comparison shots, with the new ‘Billard List’ on top, and the old ‘Poke Champ’ on the bottom.

Billard List Billard List Billard List
Poke Champ Poke Champ Poke Champ

In my 2013 write-up I talked a lot about newer versions of already supported games being added, that has also happened over the past few weeks with Capcom’s 19xx. Let’s have a look at the already supported sets.

The most common version of the game is the OLDEST known version, with a date code of 951207 (incidentally the Phoenix hacked version is also based off this version) This version has known releases for USA, Japan and Asia.

19xx 951207 USA 19xx 951207 Japan 19xx 951207 Asia

Interestingly the two regional sets for South America (Hispanic and Brazil) both came with a 951218 release, 11 days later.

19xx 951218 Hispanic 19xx 951218 Brazil

The newest set previously supported was one released 7 days after that, a Japan set with date code 951225 (Christmas Day in 1995)

19xx 951225 Japan

The newly discovered set is even newer than any of those, with a date another 10 days later, falling into 1996 this time, 960104. It’s also a Japan set.

19xx 960104 Japan

I don’t think anybody has ever documented what bugfixes were made even for the previous ‘newest’ Japan set (the 951225) one, but it’s still interesting to see development continued for a few weeks after the initial release. It is unknown if any regions outside of Japan got these newer revisions of the game. I do hope that one day somebody puts a concentrated effort into working out what actually changed between the many revisions of the games we support. I also find it interesting that there are no official European versions of the game supported, although I could say the same for Super Puzzle Fighter II.

Aside from the news posted here Roberto Fresca has continued to look at poker / video slot machine type games, you can see from his page but otherwise actual progress has been slow for the reasons I’ve already mentioned.


MEGA Annoying

I’ve looked a bit more at Mega Phoenix, and discovered one or two things. Firstly the game seems very sensitive to timing. If I bump the CPU up the 128Mhz (which is completely ridiculous for a 68k) it actually ends up transferring most of the graphics, and you can see what the game looks like, so here are some pictures of a single loop.

MegaPhoenix MegaPhoenix
MegaPhoenix MegaPhoenix
MegaPhoenix MegaPhoenix
MegaPhoenix MegaPhoenix

All is not well however, for one, that’s a gross hack, and also the game isn’t really stable and will crash if too much action takes place, the graphics flicker, the enemies are invisible in round 4, and the Phoenixship on Round 6 is flickery and corrupt too. That’s hardly surprising given the nature of the hack.

I haven’t yet tried to hook up the sound, and the port where the service mode and player start buttons are read is either multiplexed or some kind of serial port.

I also don’t know what 2 of the roms are used for apart from the initial interrupt vectors, possibly the missing round 4 graphics, but it doesn’t even attempt to transfer from unmapped addresses, also there’s a cross-hatch pattern in there which I’d expect to be used in service mode, but again no attempt to read anywhere but known addresses is made.

Speaking of the service mode.. The background graphics don’t get displayed there either (they are uploaded, but then erased?!), but this is what it looks like.


That immediately reminded me of another game I’ve worked on.. Little Robin

Little Robin

It’s the same service mode. What else did this tell me? That the VDP I struggled to emulate in Little Robin is actually.. An unbadged TMS34010. I’ve confirmed this by hooking up a TMS34010 in the Little Robin driver, and it does indeed upload code for it and run it, however the backgrounds don’t appear (much like the MegaPhoenix Service mode)

I’m not sure if there are flaws in our TMS34010 emulation, or they both need a better hookup of something somewhere so for now I’ve just left Little Robin using my old simulation of the VDP.

What it does make me wonder is if Inder / Dinamic were actually the ones who made Little Robin for TCH. The Test Mode being identical is more than a little suspicious.

Note, I don’t consider MegaPhoenix playable yet due to the issues I’ve mentioned. I don’t know how much work it will be, it depends what the source of the actual bugs is.