David Haywood's Homepage
MAME work and other stuff
September 17, 2012 Haze Categories: General News. 42 Comments on UME 0.147

UME (logo by JackC)

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

This is based on the official MAME 0.147 source release found on mamedev.org with no modifications. The binaries on offer here were compiled with ‘make all TARGET=ume’

The package contains both the 32-bit and 64-bit binaries, I’ve not included the source because it’s identical to the mamedev.org distribution.

The 0.147 release can be downloaded here.

Note: as of 0.147 the sysinfo.dat is no longer distributed with MESS, it can be found in the ‘Extra Files’ section at ProjectMESS
furthermore the external artwork files, needed by some chess computers are also not included by default. They can be found at AntoPisa’s site.

Changes from MAME 0.147 can be read about here
Changes from MESS 0.147 can be read about here

General Release Commentary

First a word of warning, there is a core issue with redefining controls for some MESS systems, including the Genesis and AES. It seems that to redefine the directions you must either redefine the inputs globally, or make sure you redefine inputs to be the same on all the selectable controller types. I’m not sure when this crept in (quite possibly a while back) but you should be aware of it. The MAME/MESS 0.147 release has the same issue, it is not UME specific.

Moving swiftly onto the release, it’s been a long time coming, u5 was released on the 20th August, almost a full month ago, so as you’d expect there’s a substantial amount in here. The ‘new working’ section is the first one most people look at and there are some notable titles in there. Ville’s continued work on Konami 3D systems means GTI Club, Solar Assault and Thrill Drive now run to a level which can be considered playable (as long as you have a beefy recent system) Hang Pilot too, although with it’s dual voodoos etc. the emulation performance isn’t great, and I can’t imagine even a top end system running it especially well. There are a number of more conventional 2D titles now ‘working’ as well. Little Robin, Magicball Fighting, and F1 Super Lap all of which have featured in updates here are promoted to playable, as is Brick Zone, an Arkanoid clone which like most SunA games is actually surprisingly good for a Korean arcade game fusing an awful lot of ideas into one little game, think Block Block or Riddle of Pythagoras if you’ve played either of those. The lesser known title on the ‘new working’ list is Ganbare Jajamaru Hop Step & Jump, although the reality of it is that it’s just some very basic and not especially interesting rock paper scissors type game from Jaleco.

The MESS ‘new supported’ section looks rather anemic by comparison, but don’t be fooled, improvements to systems like the Virtual Boy bring them much closer to playable even if they haven’t been tagged as such yet, that’s one of the things with MESS, drivers can see huge improvements but often not be tagged as working due to erring on the side of caution due either a large number of known non-working cases, or a significant and mostly untested software library. PC emulation has also seen some incremental changes, improvements to the SoundBlaster emulation, but be warned other aspects of the PC emulation are broken as various bits of code (such as the floppy support) undergo significant (currently unfinished) reworking.

Another interesting new addition is the Ghosts and Goblins prototype. While unfortunately one ROM wasn’t dumped from the PCB (and I believe it was then sold!) likely causing the incorrect colours on the text layer, it remains an interesting snapshot of the in-development game, complete with early development glitches, enemy placement, overall balance and many other things (I didn’t notice any weapon drops for example)

42 Comments

You can follow any responses to this entry through the RSS 2.0 feed.

Greetings and thanks again for this release! I’m not sure if I fully understand the; “…source not included because it’s identical to the mamedev.org distribution…” comment. Does that mean that we could download the official 0.147 MAME source from mamedev website and compile it as “TARGET=ume” to build a combined MAME+MESS build? That would indeed be wonderful. I didn’t know that the full MESS source was also included with the MAME source. Cheers

yes, you can do exactly that, as of 0.147 the source is complete and for both projects. The official MESS 0.147 binaries are built from the same source release as well.

I imagine (although it’s not been confirmed yet) that the u updates will be issued as a single update for both projects too, everybody is working from a single SVN now, so that makes the most sense.

It’s easier for bug tracking etc. when you know that the any given version of each project is built from exactly the same codebase as it’s counterpart.

UME: came in like a lion and went out like a lamb. After all the bogus reasons not to do it, the BS and consternation, UME is simply going about its business and no one even notices. Which is as it should be, and what we predicted all along.

Thanks Haze!

bogus reasons? we moved to a different server to cope with the increased bandwidth, and we moved MESS bug reporting to MameTesters… and guess what? bandwidth and bug reporting were exactly the concerns that (after all the blah blah on politics which were only in Haze’s mind) had been pointed out multiple times.

feel free to worship Haze as much as you want, but don’t try to rewrite history to suit your ideas ;)

There were plenty of political issues, there still are, please don’t try to pretend otherwise, it only makes you look silly.

In the end common sense prevailed, and as expected those who were kicking up a fuss about the possibility of things being merged just accepted it, and got on with things, but if everything was fine and dandy you’d see this stuff actually being promoted on the official site(s) too instead of being hidden away.

Personally I’m not too bothered if it means I have extra traffic here instead, but it all still seems a bit silly and artificial.

The irony is I think the public as a whole would appreciate my suggestion of making the main ‘MAME’ build a UME style thing (complete with everything, including gambling stuff etc.) and having ‘Classic MAME’ with only arcade games (no gambling, mechanical etc.) and ‘Classic MESS’ with only traditional systems (no car computers etc.) as it would give a clear official choice between having everything, and having more lightweight traditional versions which would be easier to build on low-memory systems. It makes sense to offer your most complete package as your primary thing, and then reduced ones tailored to specific target audiences, not doing so is a political decision.

I am however glad to see the single source, it makes a good statement of ‘This is *everything* we know in one package’ and that’s always been key to MAME/MESS (extending knowledge to others) even if it comes down to me to offer the single binaries.

In the end this arrangement suits me fine, but I can’t help think some people are missing out or passing on MESS simply because they’re unaware of what it can do and also due to the lack of promotion it gets, even I had to scour the forums to make sure MESS 0.147 had been released at the same time, and find the whatsnew for it. Incidentally this is why I try and write a bit about each project for every release, to promote important changes which people might be interested in and raise awareness, glad to see RB doing the same about the Ensoniq stuff in the latest builds, I’ll place a link to that in the summary later. I think the number of people who claim that MAME / MESS haven’t improved at all since 0.97 or whenever shows the need this kind of spoon-feeding / highlighting of important changes, plain whatsnew lists can be hard to digest.

@etabeta: I worship God. I respect and admire Haze. My feelings for you I’ve already made clear, and they are none of the above. Please troll elsewhere.

Dang shame MESS does not get more recognition now that it has proper testers.. now that it actually functions competently, it makes it much more convenient for organization’s sake! It eliminates the need to have a million other emulators using a front end, thus, reducing the hassle of setting one up. Really, I can’t complain about that! And even so, There’s also Seibu COP, the most EVIL protection device known to MAME kind, being improved with this release! Thanks Kale, Now we can KIIIIIIIICK OFFFF

Yes, the Seibu-related progress is quite good to see as well as the emulation improvements across the board.

Now that G-Stream G2020 has proper sound/music without the very loud glitches of last releases it may get more appreciation too, along with the MESS computer drivers.

I’m personally psyched about the recent work being done on Seibu COP. It’s pretty much all that’s left that stands in the way of MAME being ‘complete’ (not true, but from my point of view).

The problem with loading a 7zipped rom from the command line (ume nes -cart super mario bros.7z) persists though. Should I report this on mametesters?

Regards

Pooshh: There are problems with the 7zip support, especially on OS X, which I am currently working on. What is your specific problem?

The direct ROM loading code in MESS has pretty much it’s own handling for zips and the directory structures within them, it wasn’t upgraded. The code should really be made to use common implementations.

If you load via softlists you’re fine tho.

Loading 7-zipped MESS roms from the command line does not work.

For example –

ume nes -cart “/Games/NES/Roms/Super Mario Bros.7z”

returns:

Device Cartslot load failed: Unspecified error

Yeah, as I said above, the ‘direct file’ handling in MESS is a completely different codepath and duplicates a lot of functionality already found elsewhere in the project. It didn’t get upgraded to support 7z because it really needs refactoring instead.

The recommended way to run software in MESS is via the softlists, which means you’re running MESS verified roms and helps ensure any extra hardware in the cart (sram, protection devices etc.) gets emulated properly. It also helps with bugtracking because if you’re running the listed software we know you’re testing / finding bugs with the same software the developers will be using when they attempt to reproduce them. (This will no doubt become even more important once the lists can also specify extra CPUs in the carts etc. and things like the fake snesdsp1 and gensvp drivers go away)

If you want to specify direct files as you are then keep them zipped for now but it’s essentially a legacy way of doing things for many systems, it exists mainly so that you can run your own non-listed software (for homebrew development etc.) or use systems which don’t yet have actual softlists.

Small report, for whenever you plan to proceed in your MD work, something produces bogus DMA accesses in World Series 95-96-98, making the games unplayable (or crashing them internally) after a ball is hit and recceived…

This is more or less the only serious regression in nowadays code compared to old HazeMD :)

Ok, I’m trying to get softlists going, but can’t get that working. I did the following –

I’ve generated and exported a softlist for the Lynx from the ProjectMESS website, and saved it to

/emu/softlist/lynx.xml

I then put a rom here –

/emu/roms/lynx/Raiden (USA) (v3.0).zip

So when I try to run

ume -hashpath “/emu/softlist/” -rp “/emu/roms” -biospath “/emu/bios/” lynx -cart raiden

nothing happens for half a minute, and then ume segfaults.

This is the entry for raiden in lynx.xml

Raiden (USA, v3.0)
1997
Telegames

I compiled ume on 32-bit Kubuntu Linux 12.04.

first of all, you shall get the xml not from projectMESS but from

http://git.redump.net/mame/plain/hash/

because the projectmess export function you used, is thought to produce an xml dat for clrmame not for the emulator (I will make the text on the website more clear)

second, “Raiden (USA) (v3.0).zip” shall be renamed as “raiden.zip” or it won’t be recognized. its location on the other hand is perfect

finally, ume segfault might be due to any combinations of the mistakes above. retry fixing the above and tell us if it now works :)

Thanks for your help. I get the expected output when I do -listsoftware now, so that part is correct.

However I can’t get ume to find any rom.

with -rp “/emu/roms/” set, I’ve tried –

/emu/roms/lynx/raiden.zip
/emu/roms/lynx/raiden.7z
/emu/roms/lynx/raiden (usa) (3.0).bin
/emu/roms/lynx/raiden (usa) (3.0).zip

I’ve also tried setting -rp “/emu/roms/lynx”.

I just ran an old game from the console and got the following error message twice:

generic space memory map entry references nonexistant device ‘:’

A quick look at the code didn’t reveal where this comes from (I looked into addrmap and device). Can you give me a hint ?

sorry, my mistake. I forgot that lynx roms that you find around in the web have an header.

to play the rom you got, you cannot use softlists. you can play it only with “fullpath loading”, i.e. by launching

ume lynx -cart /emu/roms/lynx/raiden.zip

to use softlists, you either have to find the appropriate dump, or you can uncompress the archive you have, open the .lnx file with an hex editor and chop the first 0x40 (i.e. 64) bytes from the file, which is the header.
then, you zip up the resulting file as raiden.zip and it should work :)

running with an incorrect headered file should at least be giving a checksum warning tho, first sign of any problem

lynx raiden with the correct roms however does run in the binaries provided here at least

https://mamedev.emulab.it/haze/pics2012/lynx1.png
https://mamedev.emulab.it/haze/pics2012/lynx2.png
https://mamedev.emulab.it/haze/pics2012/lynx3.png

I know it might seem like a bit of a pain, but MESS does attempt to use correct roms where possible (using the MAME philosophy) whereas many you find for other emulators have been modified (added headers to say how the data should be loaded) specifically to work with those emulators rather than being clean roms.

Fast Eddie>

the warning means you have a device declared in the memory map structure which isn’t in the machine config structure

: however is the root device (ie the base machine) so that’s a bit of an odd error to be getting, although maybe recent changes make that invalid or something.

if it’s your own build with mods you might want to do a ‘make depend’ first to ensure important files get rebuilt next time you type make, otherwise a lot of dependencies don’t get picked up and you can get weird random behavior.

the message comes from \emu\memory.c anyway

make depend didn’t help. The message also appears quite often when I run mame -validate (usually twice per game). This wasn’t the case last time around when I built (at some point between 0.146u5 and 0.147).

I messed with the dip switches in a driver, cleaning up some minor issues, but this shouldn’t be the cause either since I didn’t touch the address maps.

eta>

wsb95/96 etc. are broken due to the sram handling in MESS

the game ends up copying data from sram instead of rom due to the overlap. this is either because the on/off toggle is wrong, or because dma should just ignore the sram altogether (which afaik was the old hazemd behavior, but seems a bit odd because sram is in cart space and would surely be seen??)

it’s possible that the old hazemd handling was wrong but worked anyway due to the above, or it’s possible the adaptation to MESS was wrong, the code is a bit spaghetti.

another scenario which would fail at the moment is if they trigger the dma then turn the sram off straight after it (which would be a bit of a crap way to program it, but would work on real hw if they were quick enough, and fail in mess because we do instant dmas at the moment) I think this is less likely however

fast eddie>

with the number of changes going in lately you might end up having to do a full rebuild, make depend isn’t perfect and only really helps for driver changes

the general core is incredibly unstable at the minute with massive changes going in all the time, so if you’re trying to stay cutting edge then you’re going to find yourself having to do full rebuilds due to the scope of the changes.

if you’re not, then I really don’t know, doesn’t seem like the type of error you should be getting just from changing some dipswitches tho ;-)

Does this mean this invalidates my whole collection? :/

make clean did the job :-). The occasional deletion of some object files wasn’t enough obviously. mame -validate is fine again and so am I.

I saw some massive changes going on, starting with very basic stuff like structs and enums and continuing with the memory management. At least aaron seems to be in a coding frenzy right now ;-).

@Pooshh: for Lynx and NES, yes, headers make most available sets not suitable for softlists

You can anyway load them using the fullpath, and they shall work

Which brings me to the next question: how can I submit code changes ? Mamedev still talks about the “old” way, sending in diffs via mail. But this doesn’t make a lot of sense under a version control system imho.

The current submission process is alive and well. Currently, I am the one the deals with such incoming mail and am endeavoring to try to keep in communication with all those who have submitted patches to keep them in the loop. This is a big improvement over how it used to be and hopefully, be it myself or whomever else might handle incoming submission mail in the future, we can keep this up as an accepted practice.

The auto-response you get lets you know your email was received. It’s light on details at the moment but it’s simply to reassure that the mail is (or will be) forwarded to the list for discussion and remind you to let us know if somehow the patch fell through the cracks after a release.

SVN write access is not handed out lightly. There is no ‘starter access’ at this time and all people who submit that do not have write access (even Haze deals through submissions) have to be patient and and work with the system. Only after a long period of quality work/code patches/improvements and other good deeds towards MAME such as being known in the community, helping others or donating time to one of many MAME related projects is definitely a plus as well.

Sorry that this is still an old system. It has proven reliable, even in it’s worse times, for worthy developers to contact MAMEDEV regarding new code.

Thanks Tafoid. If you guys are happy to walk that extra mile so am I. Just submitted my snippet and working on the next one.

i want to compile my version of mame. The last time i tried is for 0.146u2 and worked. The problem is that i want add the cave sh3 driver and i followed a guide that i found some time ago.With the 0.146u2 it worked but now with 0.147 in compile time i have this error

….
Compiling src/mame/drivers/cave.c…
Compiling src/mame/video/cave.c…
Compiling src/mame/drivers/cavesh3.c…
Compiling src/mame/drivers/cb2001.c…
src/mame/drivers/cavesh3.c: In member function ‘UINT8 cavesh3_state::flash_io_r(
address_space&, offs_t, UINT8)’:
src/mame/drivers/cavesh3.c:5825:81: error: ‘cpu_get_pc’ was not declared in this
scope
src/mame/drivers/cavesh3.c: In function ‘void cavesh3_interrupt(device_t*)’:
src/mame/drivers/cavesh3.c:6076:44: error: ‘device_set_input_line’ was not decla
red in this scope
src/mame/drivers/cavesh3.c: In member function ‘UINT64 cavesh3_state::mushisam_s
peedup_r(address_space&, offs_t, UINT64)’:
src/mame/drivers/cavesh3.c:6452:37: error: ‘cpu_get_pc’ was not declared in this
scope
src/mame/drivers/cavesh3.c:6453:88: error: ‘device_spin_until_time’ was not decl
ared in this scope
src/mame/drivers/cavesh3.c:6454:92: error: ‘device_spin_until_time’ was not decl
ared in this scope
src/mame/drivers/cavesh3.c: In member function ‘UINT64 cavesh3_state::mushisama_
speedup_r(address_space&, offs_t, UINT64)’:
src/mame/drivers/cavesh3.c:6467:33: error: ‘cpu_get_pc’ was not declared in this
scope
src/mame/drivers/cavesh3.c:6467:112: error: ‘device_spin_until_time’ was not dec
lared in this scope
src/mame/drivers/cavesh3.c: In member function ‘UINT64 cavesh3_state::espgal2_sp
eedup_r(address_space&, offs_t, UINT64)’:
src/mame/drivers/cavesh3.c:6480:37: error: ‘cpu_get_pc’ was not declared in this
scope
src/mame/drivers/cavesh3.c:6482:88: error: ‘device_spin_until_time’ was not decl
ared in this scope
src/mame/drivers/cavesh3.c:6483:88: error: ‘device_spin_until_time’ was not decl
ared in this scope
src/mame/drivers/cavesh3.c:6484:88: error: ‘device_spin_until_time’ was not decl
ared in this scope
make: *** [obj/windows/mamep/mame/drivers/cavesh3.o] Error 1
make: *** Waiting for unfinished jobs….

C:\mamesrc>

Someone can help me?

Unfortunately I can’t really support you with issues compiling the cavesh3 driver until an official decision is made to put it back in the source.

It was removed by request of the company who made the games, and I’d appreciate it if people respected that request.

There are builds out there on various underground romsites anyway, and besides you’re not going to get a very good experience compiling your own or using any recent version with the code in it because the source code to the slowpoke builds was not released (by request of the dev team)

Ok. I respect this decision.

Thanks for the reply!

I’m looking forward the first u-source update to see how the diff’s are packaged for both projects.

I’m a bit disappointed that an UME build isn’t officially eligible for MAMETesters (according to mamedevs). Most of us will still need to have a separate MAME only build for our bug reports if I understood it correctly. I still have hopes that someday in a near future that policy will or might change. Best regards

And now for something completly different… I read some of your older posts about FLAC and CHDs. You stated a couple of times that checksums shouldn’t change if FLAC is used (as far as I understand it). Now under the new v5 format CHDs must be ripped again (for whatsoever reason, I don’t know enough detail here, but let’s take it as a given, the data shouldn’t change I think) and the SHA1 checksums change. Isn’t that exactly what you were trying to avoid ? Or are the some deeper reasons I just didn’t get ?

Pls note that this is pure curiosity from my side, nothing else. In case I’m poking in old wounds pls let me know or simply ignore my question.

I was trying to avoid the checksums changing, yes.

When Aaron got hold of the code he nuked the old metadata format which CHDs created with very old versions of CHDMAN use, and it turned out quite a lot of people had been using such old versions even recently (despite them throwing away a lot more metadata than current ones)

To ensure file integrity the metadata (track info, gap info etc.) is part of the checksum, so if you force one with the old style metadata to be updated the checksums then change. Also a serious problem was found with how some GD-ROM data was stored, and so again all those had to be tagged as bad and reconverted from original sources. Any such sets ended up being tagged as BAD_DUMP in MAME/MESS and replaced with new files once reconverted from source.

You’ll notice the SHA1s of the MESS sets (Saturn, SegaCD etc.) didn’t change, that’s because they were all created with a recent version already, although even recent versions are throwing away too much information IMHO (and things like multisession are still completely unsupported + you really need faster access to the parts of the sectors used by the CD seek mechanism without decompressing entire sectors because some copy protections relies on ‘analog’ properties of the seeking)

Storing CD data is a complex problem that nobody has managed to solve properly yet, hence the ongoing ‘wars’ between dumping groups over standards. I’m sure the CHD format will end up evolving further.

Throwing away information is always an issue, fully agreed. I think I also get my head around storing issues but as you said, standards will be established or given up and things will evolve further. As long as you didn’t throw away anything (or hopefully not too much) in the first place this shouldn’t be an issue going forward, though. Except that you have to spend some computation power at some point, well…

Copy protection relying on ‘analog’ properties of seeking… sound like good ol’ C64 stuff to me ;-). Modern media, similar idea. However, getting this emulated properly is probably tricky.

Dear Haze,can you have plan to post about what left Mame/Mess work need to be done or some else what to be need improvement?

I just wanted to pitch this idea among seasoned mame devs. I’m developing my own UME frontend in Java, using Qt, and I would like to know if there would be any enthusiasm or support for a file format especially intended for use with UME. Basically, it would be a 7z archive that contains the rom, a png icon, xml file with info, cover artwork, manual, cheats, and maybe other stuff. What do you think?

Most people manage their roms with Clrmame or the like, if you start shoving extra files in there they’ll get deleted, automatically.

well, the problem which such idea is that

1. sourcing: where do you plan to take covers and artworks from? I can ensure you that most collections out there are either watermarked (spong, mobygames, etc.) or they cover only a very small portion of the games. not to mention the need to carefully examine the files to discard home-made covers (you have no idea how many floats around…)
if you end up having most sets containing only the rom itself, one wonders what was the point of a new format

2. distribution: it is already quite difficult to find complete sets of roms, due to the size of some sets. if you add the arts and other stuff, it would probably become even harder. not to mention the number of people that could not care less about arts and only want the games (I’ve encountered a few of these persons on the forums) and would just drop the format because it wastes their disk space with misc extras

3. history: there have been a few attempts so far to create similar format. the one which survived longer was Retrocopy’s GAME format, but he dropped it after around one year because nobody else was going to use it, and even handling only the systems its emu supported (just a few compared to MAME/MESS) was too much work

Overall, I think it’s easier to keep separate sets and collections for different objects: cheats are available at Pugsy’s website and pretty soon there will be history.dat for software lists taking care of infos about the games.
covers and arts are still quite spread across the web, otoh, so maybe one could try to start a serious scanning/collecting project for those and afterwards, when a sufficient number of complete cover sets have been created, there can be discussions about a format to gather everything in a single piece…

Yeah, I realize that adding officially approved artwork to the archive requires proper artwork to be available in the first place. But the easiest and one of the most useful things to add to the archive would be XML info, just like audio files contain their own metatags.

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.

Close