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.
As an end user this means that the software provided here is not only capable of emulating arcade machines like the baseline versions of MAME, but in addition can emulate a large number of home computers and consoles from across the world using the very same code, developed by the very same team of developers.
0.148u3 Windows binaries (32-bit and 64-bit) (Self Extracting 7-zip) (all MAME / MESS tools included, both 32-bit and 64-bit versions in tool32/tools64)
The source is identical to that found on mamedev.org (SVN revision SVN 22292 / 0.148u3)
Non-UME binaries
In addition to providing the UME binaries I’ve also included a package with the individual legacy MAME/MESS executables here, personally I prefer the everything under one exe UME solution but I’ve noticed it’s not always easy to find binaries of the regular u builds with them not being offered from the official site so this is my attempt to address that.
Latest U release binaries for UME, as well as MAME & MESS can also always be found on the page linked in the box on the left
These binaries are coming from Mamedev (me) so are as official as you’re going to get for a u update.
Please note, if you want to compile a linux build you should check the source out from the official SVN instead of downloading it, there is an issue with some source files and line-endings whereby the linux python scripts don’t agree with the Windows style line endings you get on the downloaded source. Details of the SVN server are still on mamedev.org
What’s New
You can read the various whatsnew files on mamedev.org
From MAME, From MESS
Points of Interest
0.148u3 is unlikely to be the most memorable u update of all time, on the surface it seems to offer very little new for the end user, and no massive strides have been made anywhere on documenting the previously unknown. It’s fair to say it’s been a fairly quiet 3 weeks, I’ve been taking a bit of a break for various reasons hence the lack of updates here and that no doubt hasn’t really helped, and we’ve seen a shorter turnaround compared to the previous u update which should also be factored in.
If I’m to highlight one thing I’d say the TMS5200 improvements were the most significant improvement in this update, mainly because the chip is used on a number of well known arcade classics such as Gauntlet and there is a noticeable increase in the speech sound quality with the latest code.
The PSX code has also seen changes, with some things improved, and others regressed. smf points out one specific example of where his improvements have helped the MAME visuals in the Street Fighter EX intro, although the biggest impact of the work can be seen more in the actual Playstation titles, where there is a significantly wider range of software. The CD changes made by Carl help some games (of note CD audio isn’t always broken now) but also apparently stop some others from booting. Either way the system is finally getting a decent amount of attention and that’s only going to help with both the arcade and home systems based on the technology.
One exceptionally good piece of news regarding these PSX changes from smf is that they actually make Night Raid and Zooo (both on Taito G-Net) playable, this wasn’t mentioned in the whatsnew (possibly not noticed at the time) but has been pointed out in the comments below.
(the PSX improvements made Night Raid work, even if it wasn’t noticed until later and is still tagged as NOT WORKING)
Beyond that u3 for MAME is more or less ‘clone city’ although it must be said one of those is a very interesting clone. A previously undumped Hang-on set was located on an incomplete boardset, it turns out this romset is for a ride-on version of the game, featuring footpedals to help cornering and a completely different track layout. Unfortunately, as mentioned, the boardset was incomplete, but only the video / sound boards were missing, and those don’t usually change, so the ROMs from the boards dumped work in MAME as you’d expect. The other slightly annoying thing is that the main CPU roms lacked the usual Sega labels, possibly as the result of a repair job because the sub-cpu ROMs had their correct labels, and appear to place the game as an earlier release than the already supported versions. The timing of the discovery is interesting because there is a lot of discussion about the track formats in OutRun over at the Cannonball (OutRun remake/port) blog.
The Dr. Mario prototype Virus is another interesting clone, a number of versions of this game, including NES prototypes (supported in the NES driver) recently showed up, one of which was a PC10 cartridge, along with ‘Bases Loaded’ also thought to be a prototype. The PC10 ones are quite an odd find, at first I wasn’t sure if they were genuine, various signs in the security part of the ROMs point at it being an unofficial conversion of Rygar, and it is known that people have been hacking and converting the PC10 titles in the past, but the likelihood of one being converted to a previously undumped game isn’t exactly high.
The newly working video gambling games are mostly (all?) clones too, even if some featured in the new games section. It’s good to see more clones found, even for classic titles like Karnov and Galaga 3, and they definitely leave the potential for somebody to pull them apart and work out exactly what was changed between revisions, they might reveal some important bugfixes, or show how the game code evolved, but on the surface they just look like the other sets right now. A lot of work has also been put into the various CPS1 bootlegs (Street Fighter clones and the like) this is tedious work for the devs concerned because the board was so heavily bootlegged and each bootlegger had their own ideas of how to re-implement things, hacking to code to suit their hardware, leaving us to have to emulate all the differences.
Both projects have seen a lot of ‘under the surface’ changes, refactoring, modernization etc. but most of that is non-user visible, things like Steel Gunner on Namco System 2 now using the proper CPU rom for the IO were significant changes, involving non-trivial improvements to the CPU core, but from just running MAME you’re not likely to notice the difference.
Under the hood we’ve also seen a couple of regression fixes, although as mentioned before I really don’t like to hype those up too much because at the end of the day we shouldn’t be breaking things in the first place, so saying they’re highlights of a new build is a bit cheap, important as they are.
The new QT based debugger has seen improvements too, and the value of having a good debugger should never be underestimated, and ensuring that Mac and Linux users have the same power as developers on Windows is vital to the growth of the project.
MESS has seen similar lower than usual levels of activity, aside from the already mentioned PSX improvements there has been continued work on the SNES mappers allows the recently surfaced PowerFest ’94 competition cartridge to run and some refactoring of the Genesis code to allow for launching of the SVP accelerated Genesis Virtua Racing cartridge via the softlists without having to have a fake ‘svp’ machine type to handle it but quiet is definitely the word right now.
The work on the MESS Genesis drivers also addressed an issue reported in the comments for the previous UME release where the 6-button pad mode would crash the 32x / SegaCD drivers.
Further fixes were made to the recently added cycle accurate 6502 series CPU cores too, although no specific games were mentioned along with the fixes but having correctly working CPU cores underpins most emulation and seeing the bugs shaken out of the new ones an essential part of their development.
So all in all, nothing remarkable, but steady progress and refinements to what is already there, possibly a bit of a downer after the last few updates but such levels of progress simply aren’t sustainable for long periods of time with the current number of developers and realistic targets left.
If anybody feels I’ve missed anything significant here, or wishes to add further details, let me know
Looking Forward
I do plan on getting back into the swing of things soon, results may vary, but it’s definitely about time I gave the fruit machines a bit more attention (I know I keep saying this, but then getting distracted by other things!) and I imagine I’ll be in a position to be able to do some tests on Puzzli2 in the next few weeks too. I think I could probably do with finding out what other devs are looking at tho, as to avoid stepping on any toes, I know Phil. B still has some impressive stuff in the pipeline, but he’s the only one I know about!
(I’ll add some screenshots in a bit, given the size of the update I didn’t think it was worth doing this post as a separate article)
Hey David, can you check if rev. 22301 helps with your reset problems in megadrive?
I’ll check over the course of the next few days, haven’t really touched MAME / MESS much in the last 3 weeks apart from compiling + releasing this and giving it a quick test run.
Based on what’s been said, and the observed behavior I’m hopeful, but we’ll see :-)
Sonikos mentioned on the Mameitalia forum that Zooo and Night Raid are now playable thanks to the recent PSX changes.
that would be excellent if true, especially Night Raid, I’ll check it out when I do the screenshots for this article :-)
good find! Night Raid has no music at all
of course it doesn’t, it’s a g-net title. you’re stating the obvious, again.
for the record, Virtua Racing works also from fullpath not only from softlist
not that it makes such a big difference, but we still try to keep support for fullpath whenever possible ;)
yeah, I’m just not a big fan of the hacks it takes to do so.. I’d still rather have some system of cartridge profiles for manually forcing a specific config (homebrew) and a ‘best match rom’ thing running the checksum of the rom(s) you present against the softlists to see if there is a profile for it in there (rather than the hsi files, which are more limited)
I guess one day (5 years, 10 years? ;-) we’ll have something like that, but until then, yeah, it works from the fullpath too, I however don’t recommend that method of using the standard consoles in MESS, the verified softlists give you more benefits for simple systems, fullpaths should really be reserved for the emulation of complex computer systems where you need the more dangerous / advanced use cases.
realy nice side effect of latest GTE fixes!
just wondering about only smf credited, afair this was collaborative work of smf and edgbla based on org/organic research
http://code.google.com/p/pops-gte/
MetalliC: As far as I’m aware smf’s GTE work is a collaboration between him and psxAuthor, both of whom have run test code on hardware.
> yeah, I’m just not a big fan of the hacks it takes to do so.. I’d still rather have
> some system of cartridge profiles for manually forcing a specific config
> (homebrew) and a ‘best match rom’ thing running the checksum of the rom(s)
> you present against the softlists to see if there is a profile for it in there
> (rather than the hsi files, which are more limited)
you keep talking about these miraculous “cart profiles”, but I still have to understand exactly what you mean… seriously, I haven’t understood what you propose: offering the user a series of profile they have to specify at command line to trigger specific slot devices?
a cart profile would be like a software list cartridge entry, without the roms, but instead markers saying ‘ROM GOES HERE’ just like a cart stripped of the game roms, but with any chips etc. still present.
this would provide a way to load any file from a zip into those positions automatically if a zip is provided and a profile selected (possibly by file extension, eg .u1 or .u2, based on the region tag names, or for single rom configurations, just whatever is provided)
you could also see if as if each IC position in the profile is something like a ‘slot’ and allow the user to manually specify what goes in each of those positions too if they don’t want to use whatever ‘best guess’ mechanism is put in.
that way people could do an svp homebrew, and specify the cart profile as the svp cart, or a homebrew for one of the carts with eeprom, and specify that etc.
eg
mess genesis -profile svpprofile -u1 blah.rom
mess genesis -profile f22profile -u1 rom1.rom -u2 rom2.rom
or in the latter case, if they’ve named their files “rom.u1” and “rom.u2” simply
mess genesis -profile f22profile romzip.zip
the existing software lists could also be updated to reference the profiles, because I’m sure many carts are exactly the same, just with different roms inside. you could name the profiles after the actual cartridge types (for NeoGeo there is an extensive list of known original cartridges types for example which influences how things load and any protection present, although handling the jumpers on them for ROM sizes could be messy I’ll admit, but true to hardware and something you’d need to know if you were developing it for use on original hw)
basically it provides a distinct separation between the cart types (which are often reused) and the ROMs, thus allowing for homebrew to be done against different profiles, without editing the softlists while also preventing needless duplication of the same information.
for normal use, nothing would change to the end user, but under the hood you have a more powerful way of doing things.
(note, that’s just an example to help you get the picture, i’m not proposing that as final syntax or anything, just showing how things could work)
Interesting idea haze. I guess it would make sense in a weird way. As I bet many of the carts used standard layouts anyway? With some being little more than big blobs of memory and others with slave cpus on them. But they probably stuck to particular layouts? Just to make it easy to swap out which ones to manufacture and did not have to tear down a whole line.
Hi David, Could you fix the sound problem “Last Fighting” and “BnB Arcade”? as the emulation of both is perfect, except no sound. Good luck with “Puzzli 2”, I am looking forward. Greetings.
Hi David. I wish you repair the sound of “BNB Arcade” and “Last Fighting”, since the emulation is very good but no sound. Luck with the “Puzzli 2” because I’m waiting anxiously. Greetings!!
Last Fighting has unknown sound hardware.
BNB Arcade uses the same chips as the Eolith games, sound can probably be hooked up, but will still sound quite bad because emulation is preliminary and the driver also has major performance issues.
Since I’m online and have tested this build, I’ll report some stuff.
SegaCD and 32X doesn’t crash with 6-button controllers now, however, Eternal Champions SCD gets caught in an infinite loop if it finds a 6-button controller during boot. This may be some kind of issue in the implementation. Fortunately, it can be worked around by just changing to 3-button controllers during the SCD BIOS screen.
Playstation fixes are good and bad. The rendering is much improved and much faster now. Madden 2002 is almost perfect and doesn’t throw endless errors. Split screen in South Park is now functional. On the downside, CDDA regressed from 148u2, so Ridge Racer is broken yet again.
And while it’s likely known, Famicom Disk System is broke.
FDS will be fixed in a few days (before next release, in any case) when the cart handling will be modernized
Stick to some older version in the meanwhile :)
Last Fighting superficially at least looks Yamaha-ish. I’ll try and remember to look at it when OG’s new H8 core lands.
WHAT THE HECK??? A Negative score? Why the heck do you have a negative score in Night Raid?
Well I have said I suck at games many times :-p
I don’t know how the scoring works tho, so beyond that I can’t comment ;-)
Quite interesting scoring system: http://shmups.system11.org/viewtopic.php?t=4855
@Haze: concerning cart profiles. as you might have noticed, if we leave aside loading multiple files, slot devices used for carts already do some of what you suggest.
The softlist loading code reads the “slot” feature from the xml and it configures the necessary add-on hardware if any (e.g. adding new CPUs or SRAM banks for the devices which require that), selecting the internal “profile” which matches the xml feature. And the fullpath loading code does the same replacing the xml feature with some heuristics.
In principle, if you go to megadriv.c and replace SLOT_OPTION_INTERNAL with SLOT_OPTION, you could already specify from command line “mess megadriv -cart your_own_homebrew -md_slot rom_svp” to load a program using SVP
The reason why I preferred the keep slot options internal, and not user-configurable, is that if you manually select the wrong option, e.g. in qmc2, you end up with a not working game for apparently unknown reason, and if you e.g. use writeconfig, you risk the slot option to become permanent in the ini file causing next carts not to work because they load the wrong slot option.
In conclusion slot devices are not so far away from you idea, as long as we talk about single file dumps.
The multiple files loading, OTOH, is definitely more delicate.
From the way you presented it, it sounded quite reasonable because you considered only cases where you have a profile for the single bin file, and another profile for the case of 2 bin files (even if, already for MD/Genesis you forgot the fact that some games have two 16bit ROMs, which have to be loaded linearly, while other like f22 expects you to load the second ROM as interleaved, because it’s only an 8bit ROM, so you need a separate profile for these)
However, after thinking a lot about your idea, I have the feeling that it would not work generally, as soon as we move away from the systems you’re familiar with.
For instance, with SNES carts you might have dumped the same game as split in different ways (say in 2 or 4 chips) due to alt pcbs being used in different production runs, like it has happened often for arcades, and you would need to create two separate profiles just to support proper location loading in the two cases.
Even worse, for NES you in general have only 1 or 2 ROMs per games, with no strange interleave or overlapping, but the cart hardware could vary *IMMENSELY* from a game to the other.
On a rough estimate, you would need more than 300 different profiles to cover the base configuration of each different “mapper” i.e. the different way the cart interpretes write/read accesses to different addresses (and the user should know all of them well enough to decide which one should be used for the game he’s trying to load) + each profile would require appropriate variants for the optional presence of RAM, of NVRAM, of a combination of both and so on because some games would not work if you specify the presence of SRAM when there should be none…
Just to give you an idea, NES SxROM boards could come with PRG+CHR roms, or with some additional volatile RAM, or with some additional NVRAM, or with PRG+CHR+NVRAM and so on… good luck implementing each profile and explaining a potential user how to use them all!
The almost complete NES slotification requires indeed ~300 new slot devices to cover all the games, but at least it can rely on some xml feature to select internally which subvariant should be use in a series of cases which your approach would probably force to split
I don’t really think any sane user would try to figure out which profile among the hundreds available should be specified in order for MESS to recognize his dump or his homebrew…
A similar situation is also present when you come to consider MSX1/MSX2 carts or A400/A800 carts, which similarly featured additional bankswitch mechanisms and/or chips on board, even if only a dozen or so of main profiles would be needed for each of these
A better way, in my opinion, would be to use something like RPK files used by mizapf in TI99. An RPK file is just a zipfile containing the dump + an xml which specifies all the configs needed to emulate the cart, in some sense as if it was a mini-softlist with a single title.
Such an approach it’s a bit annoying because it forces the user to get these xml profiles from somewhere, but given that it would be legal to host/share such profiles I don’t think it would be too difficult to find a place to offer them.
my 2c
I’m really sorry for the total off-topic-ness of this reply, but…
I saw on http://mameitalia.net/wiki/index.php?title=Happy_Jackie_(v110U)&redirect=no that you were the hacker behind the Happy Jackie PLDs dump and used Charles McDonald PAL reader to get the fusemaps.
I’m currently trying to do basically the same with the circuits of a Spectrophotometer developed in 1985 (reached its end-of-support long time ago), which has a lot of these. I found CmD project but don’t know how to open the .pcb file (tried Eagle and Proteus ISIS/ARES), I’ve found no information on how to open it on the internet . And the author states that ‘will not reply any kind of question’ on the readme.
¿How did you opened it?
Thank you very very much,
DS.
no, that had nothing to do with me, I just added the ROM loading for it, the dumping was done by the Mame Italia guys, sorry
@MetalliC None of the fixes came from edgbla or pSXAuthor or were taken from peops-gte or any other emulator. Over the last couple of weeks I logged gigs of data in mess and ran some of the more interesting examples through a ps1. Some of them were done years ago but I forgot to submit them when changing laptops.
@DarkScientist: in the readme-rev1.txt in the folder project/rev1 it states the pcb file can be opened in ExpressPCB and the schematic can be viewed with BSch3v. There are links provided to both applications. My assumption is the rev2 pcb file can be opened the same way.