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.
0.147u2 Windows binaries (32-bit and 64-bit)
0.147u2 Source
What’s New
You can read the various whatsnew files on mamedev.org
From MAME, From MESS
Obviously UME contains all these updates
Points of Interest
Starting with things I’ve looked at / worked on…
Between 0.147u1 and u2, after much suggestion that I should take the Amiga drivers under my wing by R.Belmont I decided to take a look at why the Amiga 1200 didn’t boot, as well as add very preliminary (just one or two images for testing) Softlists to the driver, including system software, to make things a little more usable to people unfamiliar with the system. Unfortunately I’ve since decided to drop work on the driver because it seems to be rather ‘hot’ with more people complaining about petty things w/regards the changes I was making than actually contributing, despite nobody lifting a finger to work on it in the last 5 years. Between all that I did however fix the Amiga 1200 boot problem, so it now boots floppies, although like most Amiga stuff the compatibility is rather low. You can however have a bit of fun with Pinball Fantasies AGA now, which is in the softlist. Pinball Illusions was also added to the softlist, but is very glitchy, probably a good test case if somebody does want to start improving the driver tho (from what I’ve seen you could probably improve compatibility 4x with some very basic improvements)
Note, due to a current bug concerning Softlists and the new floppy code the only way to successfully run it is to tell the emulator that your emulated Amiga has 4 floppy drives, which thankfully the game supports.
ume64 a1200 -fdc:1 35dd -fdc:2 35dd -fdc:3 35dd pballfnapdy
will launch the PDY cracked version of Pinball Fantasies AGA from the softlist while enabling 3 extra drives, and automatically mapping the disks to them. For reference the non-AGA version was also added, if you fancy comparing then the following launch syntax applies (due to the same issue)
ume64 a500pl -fdc:1 35dd -flop1 pballfnt:flop1 -flop2 pballfnt:flop2 (for the first table disk)
ume64 a500pl -fdc:1 35dd -flop1 pballfnt:flop1 -flop2 pballfnt:flop3 (for the second table disk)
The automatic softlist mapping doesn’t work here because the game will only look for the first course disk it finds. Course disk 3 has further cut down versions of the tables for 512kb unexpanded Amigas and MESS doesn’t currently offer that configuration. Anyway for the interests of readers, here are the games running in UME / MESS (PBF AGA has a slight glitch when you lose the ball, not shown) AGA version which runs as of u2, on the right.
As you can see, the AGA chipset and extra power from the Amiga 1200 allowed for the same basic game, but with more colorful graphics, so it’s good to finally be able to boot it in MESS. It also saw a CD32 release, which is identical to the Amiga 1200 version but with CD music, however last I tried inputs in the CD32 driver didn’t work (probably an easy fix too mind you) The prequel, Pinball Dreams was also added to the general softlist and works (well at least the pirate version)
The Amiga wasn’t the only system to grab my attention during the u1-u2 period anyway. Part of what I wanted to do was add preliminary softlists to a number of other systems, to give people a starting case to create more complete ones as well as highlighting interesting / useful test cases for further improving the emulation while actually giving some of the MESS systems a quick run through to see how well they really worked. One of these systems was the Sam Coupe, an ill-fated machine released towards the end of the life of the ZX Spectrum, building on said technology while really failing to provide anything substantial over the previous machine or 16-bit competition which was rapidly dropping in price.
The first issue I noticed was that the speed had severely regressed, running about 20% speed on my machine, this was another victim of the more flexible, but ultimately rather useless in dynamic / run-time situations due to performance cost newer bank install handling, the same thing which plagued Wardner in MAME for a while. I improved this and added the demo disk for Manic Miner, as well as a cassette for Snare (found on the b-side of the Spectrum version of the game) to the softlist. The Manic Miner demo runs, although seems too fast due, probably due to missing waitstates. Snare fails to load (black screen after loading has finished) but both do show how the Sam had more colours and screenmodes available than the Spectrum. The driver however is in need of a lot of work by the looks of it and I’m guessing, like the Spectrum is going to prove to be heavily dependent on correct timings and wait-states.
To launch Manic Miner
ume64 samcoupe manic (to start the emulation)
then within the emulation Press Enter to get past the initial boot screen, then NUMPAD 9 to tell it to boot the disk
To launch Snare (non-working)
ume64 samcoupe snare (to start the emulation)
then within the emulation Press Enter to get past the initial boot screen, then NUMPAD 7 to tell it to load a SAM game from tape (I think NUMPAD 8 is speccy compatibility mode) You’ll also have to press SCRLOCK to turn off the MESS full-keyboard emulation, and tab into the menu to get to the Tape Controls and start the tape. Unfortunately it doesn’t get ingame tho, as mentioned
Hopefully somebody can build on this and produce a more complete Softlist with some more titles and useful test cases listed in it. It seems like support for one of the main SAM Disk formats is missing, and an awful lot of files out there are demo versions, even those in the Tosec lists.
I mentioned the Spectrum above, and that’s another system to catch my eye, having owned one growing up. The problem with the Spectrum is that in terms of hardware it’s about as simple as you can get (basically a single fixed position RAM based tilemap, no sprites) however much of the software requires absolutely perfect timing in the emulation, as well as various subtle hardware side-effects being emulated for special effects. This is a problem for MESS for two reasons, firstly there is no concept of blocking / waitstates, you can’t pause a CPU mid-operation and wait for something else to happen, second even with that you’d need a sub-instruction accurate Z80 core where the fetch / execute cycle for multi-byte opcodes was handled in realtime, not blocked together, until those things happen MESS is always going to lag severely behind to level of other Spectrum emulators released in the last few years.
I also had to do some work in figuring out which Spectrum emulators were actually worth using these days, as references to what should / shouldn’t work, and while using an emulator isn’t the best reference, it’s better than nothing.
That’s not to say I didn’t do some work on the Spectrum, first on the agenda was a code cleanup, the existing driver had a very large chunk of code, and the concept of an event manager to handle rendering of the border area on the system. In reality the border area is just the area around the tilemap part, it has a fixed colour determined by a 3-bit register, nothing more, nothing less. Special effects, and loading effects happen on this border simply because that register can be changed during the active display, so you can change it on different lines, or even in the middle of lines; many demos use this and a knowledge of the system timing to actually draw blocky graphics in the border area. The MESS code was excessive and confusing, trying to buffer up all the screen changes into said event list, so that it could be rendered later. In reality all you need to do is get the current display position from MESS and render with the current border colour up to the current position, much easier.
The other issue with the Spectrum driver is that it hadn’t been touched for many years, there were some old legacy MAME hacks in there from a period where MAME couldn’t handle fetching of a z80 opcode across different banks etc. These could be cleaned up too. For some reason the 128 systems also had the ROM area set to writable, so games could trash their own ROM, not good. Overall timings and CPU clocks for the 128 systems also didn’t match reference material, although fixing those actually caused some more issues than it fixed which I’ll still need to investigate, but given how little of the timing we have correct anyway there probably isn’t much I can do about that at this moment in time.
The TZX handling in MESS also needed attention (and still does) TZX is a ‘compressed’ format for storing tape data, it attempts to represent all the data on a tape with a number of block types, and is flexible enough that you can encode the same thing in many different ways, add comments etc. Several of the cassette images I had used block types not supported in the MESS parsing so they were simply being ignored, one such missing feature was the ability to loop blocks, which a number of tapes images used to compress protection information (a series of short pulses / tones repeated many times) adding that, and one or two other bits has helped to improve compatibility with a number of tapes, although there is still much work to do, and some uncertainty over certain aspects of the TZX format, which I think various people have implemented in different ways, and possibly means some images might not even be perfectly to spec. The MESS handling is certainly wrong, but because the protections are incredibly timing sensitive as well it can be hard to know which issues are caused by what.
Anyhow, I added a preliminary placeholder software list there too, where I can list TZX images I’m working with in, and note good test cases for the emulation, like with the other systems. It helps to keep everybody on the same page. I wanted to do a similar list for Spectrum +3 Disks, but the new floppy code can’t currently handle the ‘.dsk’ files (or extended variations of them) which also means the Amstrad CPC floppy list handling is completely broken at the moment too. Hopefully this is just a temporary issue and Olivier, who is working on the new floppy code, can restore support for the format, even the old support didn’t handle the protected disks correctly.
That’s a big block about MESS anyway, for my work on MAME see the previous updates here, not much more to say about them, u2 had 3-on-3 Dunk Madness etc. No real progress has been made on the Puzzli 2 stuff yet because I put it on the backburner while I took a look at the above things in MESS, and I can only work on so much in a given period ;-)
When it comes to work other people have been doing there’s also some good stuff in u2. iq_132 has been putting in an effort to remove a lot of ROM patches in the MAME source, usually where protection devices haven’t been emulated properly, but rather the ROMs patched at runtime to avoid any issues. Many of these are trivial but it was simply quicker / easier to patch out the offending code at the time, than figure them out, some are more complex. From the point of view of an end-user it’s unlikely (and obviously preferable) if you don’t notice any difference, but from the point of view of keeping the emulation clean it’s always one of the goals to be able to run the original, unmodified code rather than cheating by patching things out. Some of the higher profile cases of his work include Metal Slug X, Caveman Ninja, an actual bugfix to the Knights of Valor protection simulation, and SunA’s Ultra Balloon. iq_132 doesn’t have a dedicated WIP page, but he does mention this work in the forum thread he usually uses to show what he’s been working on in Final Burn Alpha over
Speaking of SunA, that’s another hot topic right now and u2 includes Luca’s progress on Sparkman to add to the list of working SunA titles supported.
For MESS, R.Belmont has continued his undisturbed work on the earlier Mac systems, adding support for a host of new peripheral cards, Curt Coder his c64/c128 work, Olivier floppy / floppy controllers, smf SCSI rewriting / refactoring, and Mooglyguy has been improving something called ‘Craft’ which I have no idea what is, but he posted some screenshots of the bannister.org (MESS WIP) forums, looks demoscene-like.
I started by talking about the Amiga and Pinball games, so on the topic of Pinball games Robbbert has continued working on fleshing out the skeletons for the actual mechanical ones, as mentioned last time, not especially useful right now, but it does position MAME for potential reworking into a more modern PinMAME port based on the current codebase, although there’s still a long way to go before that happens.
Aaron has been pushing through more code modernization which seems to be low impact (not observed any breakage as a result) we’ve also seen various i386 improvements. For shits and giggles I tried installing Windows ME on a 486 in MESS by forcing it to ignore the hardware checks, amusingly it actually installed, only crashing the emulator once during install (same as Win 98) but it took over 12 hours and was really too slow to use, ran in 16 colours because I don’t think Windows ME works with any ISA / VLB video cards, and only had 3 meg space left on my virtual 500MB HDD after install, not recommended unless you don’t value your sanity ;-)
Finally Roberto Fresca has continued his dedicated work on old video gamblers, and dealing with the mess many operators left behind.
As you can see, it’s been more of a MESS focused update this time really, which makes a change from the last couple where most of the changes have been to the MAME side.
“For shits and giggles I tried installing Windows ME on a 486 in MESS by forcing it to ignore the hardware checks, amusingly it actually installed, only crashing the emulator once during install (same as Win 98) but it took over 12 hours and was really too slow to use, ran in 16 colours because I don’t think Windows ME works with any ISA / VLB video cards, and only had 3 meg space left on my virtual 500MB HDD after install, not recommended unless you don’t value your sanity ;-)”
For some reason this is the most hilarious statement I’ve read in ages, I can’t stop laughing.
On a more serious note, since it actually installed, that seems to show that the hardware checks were entirely artificial back in the day, forcing you to buy better hardware. Very conspiracy like =).
Thanks for the long and interesting post.
Yeah the Windows installers have flags to bypass the hardware checks.
Obviously most of them are for sanity reasons, for example here I’ve found out there really don’t seem to be any drivers for the older hardware, so you’re stuck in low-res 16 colours, so as much as the rest of the code runs you probably don’t want to run it ;-)
I don’t know if you can force Windows 2000 to install the same way, or if they actually started using Pentium instructions at that point, I know XP and above do actually require newer processors.
Some of the modern Linux distros can be installed too, things like DSL (Damn Small Linux) complete with Firefox, although afaik there’s no networking support yet, and it’s still painfully slow as you’d expect; MESS / MAME are eventually going to need a recompiler to have a hope in hell with x86 hardware emulation.
I used Windows 95 on a 486 computer with a VLB video card. I think it was a Tseng Labs 4000 (or something like that) and I’m also reasonably sure that it had a driver and supported 24-bit color. I also had another VLB card that used a Cirrus Logic chip. I believe that also came with driver disks for Windows 95.
It seems like they should also work in Windows ME unless something major changed under the hood between 95 and ME.
“MESS / MAME are eventually going to need a recompiler to have a hope in hell with x86 hardware emulation.”
Have you looked at what they did with Bochs (which I think is 100% interpreted)? They were basically in the same boat with how well it ran. They went thru and changed the way things are cached and decoded and got some pretty good speedups (from unusable to could use it in a pinch). In some cases as good as a recompiler. It could be a matter of thrashing the real cpu cache (which was a good portion their problem, as well as slow logic for decoding flags which x86 uses the hell out of). As I know windows does all sorts of crazy things like self modifying code and the like. I highly suggest reading No-Execute by Darek Mihocka (ignore the hyperbole). He does have some pretty good ideas that may help a lot. He also has some decent test utilities that run in windows so you can figure out what is going on.
I haven’t, I tend to stay away from the CPU core area of MAME myself.
There are some obvious bottlenecks in the MAME system, the memory system is obviously cited as one of the more expensive ones.
The problem is, as always, you can design something to work in all cases, or you can design something to work in 99% of cases. As I mentioned in the main article, I was able to remove some hacks from the ZX Spectrum driver relating to opcode fetching in an edge case; old MAME versions just got a pointer to a memory bank and fetched 2-4 bytes based on that pointer which was fine for 99% of cases but failed if the memory was on the boundary between 2 banks for instance (there used to be a lot of hacks in MAME to deal with this) Now it will just go through the memory system for all 4 fetches, not quite as fast, but reliable without having to consider where you might need ugly hacks. The recompiler cores actually have mechanisms for cheating in cases like this, because typically the CPUs using them aren’t using heavily banked memory.
That’s just an example of course, I have done some profiling of certain MAME cores in the past and been unable to come up with any sensible speedups without risking breaking edge cases. Cache thrashing has been a concern (and can be difficult to nail down) but I’ve seen little evidence of it.
I’ll admit, I haven’t done any profiling of the x86 cores, I think the most important thing is for people to nail down the behavior first, you don’t want to optimize yourself into a corner :-)
>although afaik there’s no networking support yet
There is, although you need to build with USE_NETWORK=1, and it works in dsl.
>As I know windows does all sorts of crazy things like self modifying code and the like.
We don’t use any shortcuts in the i386 emulator right now, it’s all emulated in a simple and admittedly rather slow way. Like Haze says, behavior is the focus currently.
me: That’s roughly how ElSemi got the speed in his Model 2 emulator. There’s no DRC on any of the CPUs; instead he caches the decode information for each instruction which greatly speeds up interpreting the opcodes. This obviously gives a better boost on systems with complex decodes and/or variable length opcodes (x86, various DSPs) than it would on e.g. 680×0 or something.
For MAME if you’re going to that amount of work you may as well just go DRC, I think.
@Arbee
I think most of what bochs saw was ‘if pushing’. Where instead of on every pass of every instruction doing some if condition only doing it in cpu instructions that really needed it. He also came up with an interesting way of decoding instructions which minimizes branch misses in the real cpu. The only thing I think they cache is tlb lookups. As that can be expensive (2-3 more adds shifts and muls and a memory lookup).