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.

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.

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.

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.

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



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



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.



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.

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.

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

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.

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

With the 2013 write-up out of the way here is another UME build.

I was hoping that 0.153 would be out now with the u releases gone and a plan to possibly release full updates a little more often but it appears it is still some time away. This is understandable because there have been some fairly major bits of code restructuring under the surface over the last month and quite a few known regressions that needed fixing, so probably plenty of undiscovered ones too. For that reason this might not be the MOST stable UME build ever (I’m not sure, it might be fine, most of the major problems have been fixed) although it works for the recent additions at least.

0.152ex3 is based on SVN revision 28034

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.152ex3 Windows binaries – 32-bit, 64-bit and all tools
UME 0.152ex3 sources

Points of Interest

(more to come)

One thing people have noticed from the SVN logs is that Andreas Naive put in some code to decrypt the 036 CPU type used by PGM2. This does not mean PGM2 emulation is imminent, actually, what we’ve discovered as a result means it’s less likely than ever. The code in the external PGM2 roms is for an ARM11 CPU, there are THUMB2 opcodes in the thumb part of it. Currently MAME only emulates up to the ARM9 and original THUMB instruction set. Even if we were to emulate the ARM11, ARM11 CPUs are usually clocked very high, and MAME struggles even with the 200Mhz ARM7 used by “touryuu – Touryuumon” (Eolith Ghost hardware) Emulating an ARM11 would be even slower than that, I don’t know what the exact clock is but I have a feeling the PGM2 system likely has enough power to be emulating a PGM1 unit.

Furthermore, like the 027A the 036 has an internal ROM for each game, because it’s newer technology those are likely to be even more well secured than the 027A ROMs. In other words, it isn’t happening, and even if by some freak chance it does happen it will run at 2fps.

Oriental Soft were a Korean developer probably best known for the titles 1945kIII and G-Stream 2020 (which was produced by Oriental Soft Japan). It is also one of the ancestors of Triangle Service who would go on to make titles like XII Stag and Trizeal.

We (the MAME development team) were recently contacted by a se yong Jang, informing us that he was the main programmer of another Oriental Soft game ‘X2222’ and that he would like to see it emulated. *edit* He has kindly filled us in with some further history of the game, it’s development, and the involvement of Promat in the comments below

We were forwarded several roms, including graphics and two raw ‘.HYE’ hyperstone object files. For one of the .HYE files (an older, prototype revision) we were also supplied with a ROM binary. Unfortunately we don’t know exactly how to convert the other .HYE file to a ROM binary and it seems the one we do have as a binary doesn’t quite match the sprite graphics we were given. No Sound ROM was supplied either.

The hardware, as it turned out was a variation on G-Stream. Much of it was the same, sprites, 3 layers of tilemaps etc. except for one critical difference. Instead of using 8bpp indexed graphics and a palette this game actually stores raw 16bpp RGB data in the graphic roms (meaning you can only have half as many graphics in the same space and can’t do palette effects with them because the colours are hardcoded as part of the data)

MAME can’t handle 16bpp data directly with the regular drawgfx and tilemap functions so I had to write custom functions in order to render this data correctly.

Eventually I got the game mostly working, there seem to be some sprite wraparound issues that need further investigation, but it boots and can be played.

Unfortunately there’s no sound due to the lack of any sound ROM (I’m assuming it’s missing rather than it simply using some kind of YM chip, I should probably check tho)

Furthermore the graphics for all the bosses after the first level are corrupt due to the mismatch between the program rom we’re using and the sprite roms we’re using, the tiles referenced by the program don’t match up.

Finally the code we’re using is for a 5 level prototype of the game, after beating the 5th boss the game simply returns to the title screen. It’s possible the .HYE file we haven’t figured out how to convert is for a more complete build.

Obviously this is quite an unusual scenario, but I thought some people might find it interesting :-)

(Below you can start to see where boss graphics are corrupt due to mismatched sprite & program roms)

Thanks to se yong Jang for his involvement in this, it will be interesting to see if a more final version turns up, or the correct sprite roms for this prototype build.

I’ve taken the password off the 2013 write-up article.

This is still a bit of a draft, so some text needs refining, but I hope it covers all the major developments at least.

It’s taken a lot longer than I wanted because my initial version (which was ready for the turn of the year) was only around 1/3rd the size of the 2012 write-up even after I’d covered all the bigger bits of progress in MAME and the key points from MESS as I did for the 2012 one, this required a lot more digging because IMHO we’re continuing to see a shift to where most development is done for non-arcade platforms, and as I’m less involved in that side they need more research.

If you feel I’ve missed anything significant (make sure it wasn’t already in the 2012 article, or hasn’t happened in 2014) then make sure to let me know.. Otherwise enjoy an awful lot of screenshots etc. showing what has been done over the year. All but one screenshot was created specifically for the article during my testing so needless to say creating the article has been a ridiculous amount of work, that’s why I’m publishing it now rather than waiting another month until I’ve proof-read it all.

I’m not sure when the next MAME release is, I might try to put up a UME build soon although there have been a lot of major restructuring changes over the last few weeks so I’m not entirely sure the code is all stable at the moment.