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.
Haze, you really chose a bad SVN revision to base a preview release on. Maybe you didn’t notice but yesterday Couriersud accidentally committed a bunch of very unfinished CRT simulation stuff he’s been working on (software HLSL, more or less) and as a result in this build the sliders menu is crufted up with a bazillion new sliders that either don’t work or crash the emulator if you touch them. His accidental commit broke other stuff like -listxml as well.
Couriersud’s unfinished code was committed in r28003 and reverted in r28041. I think you should take these binaries down and replace them with r28041 or later ones.
I was actually going to highlight Couriersud’s stuff as a positive point when I added more to the text here, it looks kinda neat even if it’s slow.. but I do see he reverted it.
I have no intention of taking down the binaries tho, they are what they are, if people leave the options alone I don’t think they have any real impact on stability, and if people turn them on things are so slow they’ll quickly turn them off anyway, also I picked a build after the listxml memory issue was fixed ;-)
Another highlight for shmup fans: preliminary ZSG2 support, used in the Taito FX1 and G-NET arcade platforms. Sounds incredibly tinny at the moment (will we see the TMS57002 implemented any time soon?), but it’s finally there showing signs of life. :D
yeah, that’s definitely one of the highlights of the last few weeks, has had quite a dramatic effect on performance, but good to hear some signs of life from it.
Sorry for not getting around to writing about this release yet, I’m trying to look at some extra emulation stuff instead, I’ve spent most of the last 2 months doing write-up stuff for the 2013 article ;-)
Hello there!
You have an excellent project! I am enjoying it very much!
I have been wondering, why have the developers never worked on support for Star Trek Voyager: The Arcade Game? It was 2002’s Video Game of the Year, and is loved by Trekkies and non-Trekkies alike. You would think they would work on support for such a popular game, rather than hunting down obscurities no one’s ever heard of.
Any thoughts on this?
The hardware is just a ‘modern’ (for the time) PC platform. It’s not really a realistic target at present, it would run at about 3fps, similar to the Chihiro driver. There aren’t really any developers who want to work on things that are going to be that slow, it’s just impossible to debug / know things are working correctly.
Being popular has nothing to do with things.
sounds like you need to upgrade your cpu ;)
While the slowdown is understandable we need to be much more mindful of performance than we are being.. it’s really not doing our reputation any good.
I see… Oh, well. I guess I’m just gonna have to look into it myself. Thanks anyway! Keep up the great work!
Voyager was popular cos even the girls liked to sit in it and watch shit go by. It was a ridiculous game. Like the show. kin ‘ell.
>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.
The u releases were dropped after the case was made that they were pointless because nobody used them. The people making those arguments might have hoped that releases would happen quicker, but I don’t recall that being discussed.
Full releases will likely happen at the same rate as they would whether u releases are happening or not. Although with people switching to pulling the code from svn then there is even less reason to do a full release.
With a long time between releases and no real exit conditions then I expect full release quality to become worse too.