As it transpires the release of MAME 0.145 was meant to come with a ‘promo’ combined MAME / MESS build, at least that was the plan at one stage. Why that didn’t happen I don’t know. Maybe concerns about the overall stability of the 0.145 release giving a bad impression, maybe a lack of time, maybe some more boxes needing to be ticked with various devs, maybe some last minute conflicts which prevented it going ahead. Either way, it didn’t happen.
Anyhow, there was some *official* code written for this purpose, similar to the last Ultimate patch I posted, but stripped down a bit further to the bare minimum of changes needed to build it. The code, written by Micko (MESS Co-ordinator) has been given to me, and I’ve uploaded it here. That code builds a variant called ‘universal.exe’ / ‘universal64.exe’. Given that it was the plan to include it at one point I’m cautiously optimistic that this may yet see the light of day in the official source trees (and maybe even as binaries) but we’ll see.
Personally I find ‘universal.exe’ a bit of a mouthful, so in building a new EXE myself I’ve shortened that to simply ‘uni.exe and ‘uni64.exe’ (UNIversal emulator).. actually UNE (UNiversal Emulator) would would also be a reasonable executable name. But, minor detail, this combined build has yet to really be given a proper name, so for now I’m still just gong to call it ‘Ultimate MAME’
Ultimate MAME 0.145+ (MESS SVN r14446) (GIT rev)
This as suggested is built from the MESS SVN r14446 code. It includes everything from the MAME/MESS of that revision, including the 7-zip support for ROMs.
As an additional option I’ve included extra binaries which are built as ‘MESS’. Those binaries will identify themselves as ‘MESS’ to external applications instead of Ultimate/Universal/MAME. This is done for compatibility with the QMC2 frontend. The MESS Version of the QMC2 frontend can be used with the ‘MESS’ binaries, because as far as it’s concerned it’s just a build of MESS with additional arcade titles. The actual MAME version of QMC2 is more stripped down and lacking in features needed to run various systems included in the Ultimate version, so you have to trick it into thinking it’s running MESS. If you’re not running / wanting to run QMC2 you have no need for these binaries.
EASY WAY, FOR THE LAZY
64-bit link (RAR) (includes resources, source, 64-bit uni.exe binary, and a 64-bit all-inclusive binary built as mess.exe instead for if you want to use QMC2)
32-bit link (RAR) (same as above, but 32-bit)
MANUAL WAY, FOR THE TECHNICAL
the following patches were used
Universal / Ultimate MAME build target
Patch to resolve build conflict with ‘bullet’ (name was used for both Wave Mate Bullet in MESS and Sega’s Bullet in MAME)
APE support patch for Samples (not vital but you can play with it if you want, see prior update for details)
SVN r14446 Common MAME/MESS Resource Files YOU WILL NEED THIS FOR ANY OF THE BINARIES / SOURCES BELOW TO WORK CORRECTLY (it includes the softlists, and artwork used by a number of MESS Systems)
Source code for builds below (patches pre applied)
64-bit Binaries (with tools) (drop these in the folder where you extract the above resources)
32-bit Binaries (with tools) (or these if you’re on 32-bit)
64-bit Binaries (with tools) (built as MESS)
32-bit Binaries (with tools) (built as MESS)
(note, to build like the above 2 just copy mess.c (from /mess) over uni.c (in /uni) renaming it to uni.c, obviously)
—-
Due to the change in build process (using the Official patch instead of my own) there is a slight chance that some things might not behave quite as before, for example in my own builds I was making sure that the same CPU cores were built by each project, although with the modern MAME architecture it looks like such concerns were unnecessary (it used to be if you changed the CPU cores included you had to do a full recompile) Everything here is built first by building MESS (make) then building the Ultimate / Universal build using that as a base (make TARGET=uni) Finally tools were built (make tools)
—-
I usually provide a demo of some of the cool stuff / comparisons when I post one of these builds, but I haven’t really had much time to do anything like that with adding the various 7-zip, FLAC, APE and JPEG support as shown in prior posts. I’ll try and find something worth showing in the coming days tho, there is a lot of neat stuff happening in MESS lately such as the ability to run old versions of MAME on the 486 driver, but it doesn’t make for much in the way of screenshots, and it is a little slow to be of practical use regardless of the ‘cool’ factor it has :-) ..
Ha, what if you’re not lazy but instead incredibly motivated and hampered by technical incompetence?
Thanks for the cool new builds, downloading now….
no problem, hopefully there won’t be any new issues aside those which exist in the main code at the moment.
Usually these things get a bit of testing by me in the days prior to me deciding to do a release or not (general assessment of the current project stability) but as I outline in the last paragraph I’ve been busy writing some actual code lately, and not had the chance to run much.
UltimateMAME, Universal Emulator…
You could always just call it MEME (Multiple Entertainment Machine Emulator) :P
latest MESS can also run the first MESS release, in addition to older MAME ;)
http://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=77213#Post77213
‘UNE (UNiversal Emulator)’….. *perfect* moniker.
Yeah, I’m moving towards UNE being my preference too. Universal.exe is too long, Uni.exe is a bit too generic.
If it’s to be officially included ‘une’ as the target name would definitely get my vote at this stage.
I always dreamed of such a combination being called ACCESS (Arcade, Console & Computer Emulation Super System), but I think a little-used database program by Microsoft may cause issues there.
Perhaps USE (Universal System Emulator)? I find the command “use puckman” rather amusing.
great! tools are compiling again with this stripped down patch!
all green on osx lion@64 and gentoo@64!
Great work! This is going to get confusing real quick though, what with the console roms playing with the arcade roms and all.
hmmm…. acronyms
M.E.M.E. actually works… but it stands for “Multiple Electronic Machine Emulator”
perhaps M.E.D.E. (Multiple Electronic Device Emulator)
M.A.C.E. (Multiple Arcade/Console Emulator) I like that one… it’s sounds violent like MAME >:)
M.E.E. (Multiple Electronics Emulator)
Of course if you don’t reall care about what it stand for, Ulti-MAME sounds best….. ultimate mame is a little lengthy, just go for a pun on words.
Testing the latest changes in NeoRaine, I’ve found at least two raster related bugs in MAME neo turf masters, if anyone is interested.
Apparently raster emulation isn’t well understood. (Beyond that I’m always surprised at the things still wrong in games that have been emulated for a LONG time.)
I’m reporting it here because I’m using UltimateMame to test, and signing up at http://www.mametesters.org/ seems to be a procedure only a programmer could love.
The raster implementation in MAME is 100% tested on real hardware, and verified against the developer documents too…
I have noticed rasters seem to be off in places, but I do wonder if they weren’t just off on the original HW. Other timing differences / delays might be causing it tho.
Raine uses cheap hacks to do rasters, like everything else (or at least did last time I checked) simply using the scanline of the interrupt rather than when the actual change happens. It makes the rasters less sensitive to other timing in the emulation, but isn’t the correct way to handle it.
IMHO it’s a classic case of emulating something properly ending up introducing far more factors to deal with than just going the easy route.
just a note sms (sega master system) is broken in this build due to a conflict with the MAME ‘sms’ driver
both have a ‘class sms_state’ but it’s actually different, causing it to fail.
I’m surprised the linker didn’t scream murder at me over this, but I guess it wasn’t detected.
I’ve submitted a change MAME-side to rename the MAME one to smsmfg_state
I don’t know how to interpret “cheap hack”…
Raine had no rasters at all until a few days ago. The Neo Geo developer manuals were kindly posted in the FBA forum which gave Tux what he needed and AFAIK he’s implementing everything exactly to spec. I’m not sure how much you can cheat on rasters anyway without them really fucking things up, so I assume you have to toe the line pretty tightly.
What I’m trying to determine is if Neo Turf Masters works in MAME like in real life. On hole two of Germany there is a black line that looks like it shouldn’t be there:
[img]http://i40.tinypic.com/2v9c7d3.png[/img]
On hole one of Japan the moving clouds are cut off two rows two soon.
Of course it’s possible the game is buggy, not MAME’s implementation of Neo Geo.
From http://rainemu.swishparty.co.uk/msgboard/yabbse/index.php?topic=1624.msg6273#msg6273:
[quote]I really think that some games contain code which worked “by accident”, they saw it worked, so they kept it like this without trying to understand why. Well now it’s our problem if we want to emulate it ! ;-)
After taking a look, the difference is on the number of lines used by the vbl before the visible screen starts.
Stay here, it’s not so easy, this game doesn’t work like what the theory says, so there is probably a bug somewhere.
The theory says (http://wiki.neogeodev.org/index.php?title=Display_timing) there should be 1st 8 lines of synchro, then 16 lines of invisible border, 224 lines of physical screen, and then another border of 16 lines, which makes 264 lines.
Well if I take this I get an unstable picture on neo turf masters, so I had to use 12 lines of sync instead of 8 so that it has enough time to redraw its screen normally.
Now the place you found is clearly a place intended for clouds animation (if you wait long enough, you’ll see the mountains tops finally fit exactly the moving parts, the animation should start 8 lines higher at least so that only the clouds move, not the mountains top !).
But with 8 more lines, you get a sync area of 20 lines, which is quite ridiculous !
If I take this number, then on the 1st save you sent, you clearly see the nearest trees are cut at the bottom (with the number there is in the current release they are also slightly cut, but it’s barely noticeable). With 8 more lines it’s really very noticeable !
What I am trying to say is that you can’t have all the places to look perfect, there is a bug somewhere in this game.
But the bug might be with the missing lower part of the trees using this astonishing new value, because with it, riding hero has a road which looks like a triangle when it’s straight, exactly like on this video :
http://www.youtube.com/watch?v=HmoV6skvKys
So the screen would start at line 36 and not 24 ? That’s very far from theory here !
The ideal solution would be to be able to check on the original hardware what neo turf masters looks like at these specific places. Well unless someone shows here with the console and the game, we’ll never know !
Anyway the change is extremely easy to do, only 1 line to change, change START_SCREEN to 36 instead of 28.[/quote]
So, I’m just trying to make sure how Turf Masters is supposed to look, and AVOID any hacks.
If you say that MAME has it exactly right I’m more than happy to take your word for it, that’s why I asked here. But I have to ask because the changelogs show games being corrected for very basic things like crystal frequencies, or the frequency of sound effects, or the shade of a color, which makes me as an end user unsure if ANYTHING can be said to be done and done.
One question if I may: Are rasters updated once per horizontal scanline, or can they be changed in the middle of a line too?
Darn, my comment disappeared.
Raine had no rasters at all until a few days ago. The Neo Geo developer manuals were kindly posted in the FBA forum which gave Tux what he needed and AFAIK he’s implementing everything exactly to spec. I’m not sure how much you can cheat on rasters anyway without them really fucking things up, so I assume you have to toe the line pretty tightly.
What I’m trying to determine is if Neo Turf Masters works in MAME like in real life. On hole two of Germany there is a black line that looks like it shouldn’t be there:
[img]http://i40.tinypic.com/2v9c7d3.png[/img]
On hole one of Japan the moving clouds are cut off two rows two soon.
Of course it’s possible the game is buggy, not MAME’s implementation of Neo Geo.
From http://rainemu.swishparty.co.uk/msgboard/yabbse/index.php?topic=1624.msg6273#msg6273:
[quote]I really think that some games contain code which worked “by accident”, they saw it worked, so they kept it like this without trying to understand why. Well now it’s our problem if we want to emulate it ! ;-)
After taking a look, the difference is on the number of lines used by the vbl before the visible screen starts.
Stay here, it’s not so easy, this game doesn’t work like what the theory says, so there is probably a bug somewhere.
The theory says (http://wiki.neogeodev.org/index.php?title=Display_timing) there should be 1st 8 lines of synchro, then 16 lines of invisible border, 224 lines of physical screen, and then another border of 16 lines, which makes 264 lines.
Well if I take this I get an unstable picture on neo turf masters, so I had to use 12 lines of sync instead of 8 so that it has enough time to redraw its screen normally.
(continued…)
if you put links in your posts they end up in the spam filter…
anyway, as I said, Charles Macdonald did *extensive* tests on the HW way before any docs were available.
it would be easy to hack both those bugs to be fixed, or adjust things to values which we know are wrong, it’s much harder to fix them properly, so they get left.
I believe the point at which the displaylist is read was established, so you can’t make effective changes in the middle of a scanline. (except maybe palette ones, I’m talking purely about the object list here)
Now I don’t know your level of understanding of the raster effects, or raster interrupt, but a lot of emulators take a shortcut, and simply assume the line on which the raster interrupt is requested is the line on which the scanline data will be changed, and update to that point. In reality the raster interrupt is just a *guide* it causes an interrupt to occur on a given scanline, code gets executed at that point, that could could run for 20+ scanlines before it ACTUALLY changes the video data so in reality the 20 lines after the interrupt wouldn’t actually change at all. Usually they aim to run code which can be executed in a scanline, but sometimes it does run over. It’s ALL about timing and when the video writes occur, and nothing at all to do with when the interrupt occurs. The cheap hack / assumption others use is easier, and works better in many cases, but isn’t how the hardware works.
It does sound like Raine is actually trying to emulate the rasters properly unlike everything else, but they’ve decided on a different set of values. The very fact they’re using a different 68k core (StarScream) with different timings means that the time taken to execute code in some cases could be pushed over a scanline limit, throwing rasters off by 1 if it writes the VRAM changes on the wrong line. Likewise it’s not impossible there are timing issues in the MAME 68k although the core is more mature than StarScream. Timing bugs are evil, and basically not something you can fully understand without the hardware sat in front of you, and even then there are a multitude of issues which could throw things off.
I won’t be touching the NeoGeo video code, I consider it absolutely off-limits considering the work that’s gone into it. I do have a feeling it’s not quite right (ZedBlade has some very visible issues too) but there are people in a better position to work out what needs further testing and actually test it than I am. Making random stabs at fixing it when others have actual hardware they can test on isn’t an effective use of my time, and the system in incredibly dull to boot. The only NeoGeo thing I’ll be doing in the near future is hooking up the CD unit ;-)
It’s also one of those systems, where video evidence is imperative considering how many games have OBVIOUS video bugs on the real system. Nobody is even going to consider taking a report without it. Even the Raine guys, as you can see have doubts that all cases would be correct on the real HW. I’m pretty sure the entire SNK QA process consisted of just the tea lady looking at the screen and saying “that’s pretty”
Thanks for the info re StarScream timing.
Regarding rasters, do you know if scanlines get updated mid-scanline? Or once per scanline?
“It does sound like Raine is actually trying to emulate the rasters properly unlike everything else, but they’ve decided on a different set of values.” I thought there were only one set of correct values…is “8 lines of synchro, then 16 lines of invisible border, 224 lines of physical screen, and then another border of 16 lines” not correct?
“it would be easy to hack both those bugs to be fixed, or adjust things to values which we know are wrong, it’s much harder to fix them properly, so they get left.”
AFAIK Tux would be happy to implement rasters properly and perfectly. Once everything is emulated perfectly, bugs and all, is the time to start hacking.
One problem is lack of documentation on how the Neo Geo works. We have the developer docs posted in the FBA forum but as everyone knows there are always details missing. I welcome links to any additional Neo Geo programming documentation. Maybe there is a summary of Charles Macdonald’s findings so one wouldn’t have to read the mame code.
Someone with the real hardware has to actually say “yes, I have this game and it’s not supposed to do that”. Now I realize how valuable those screencam videos are to developers.
Ah you updated your post, I think you answered my question about timing, thanks mucho mi amigo.
FWIW, starting from 0.144u1 and Micko’s changes to makefile, there should be no differences due to which emu you compile first or if you directly compile UNI and then you type “make TARGET=mame” and “make TARGET=mess” (which would then just link the available .o files). so in principle there should be no need to specify that you first compiled MESS and then the universal build
of course, this is assuming no other sms_state-like issues are present and that the compiler tools do not suck (which we know they sometimes do, at least for 32bit XP) ;)
eta> I’ve been compiling MESS first out of habit, the issue was always with the tools, not the emus anyway, but I’ll try compiling ultimate first instead to see if it still occurs
mickos solution isn’t going to have changed the linker errors there, and I haven’t seen a check-in specifically to deal with them, but maybe they’ve just been fixed by something else.
nah, there are still issues building the tools if the target is set to ‘uni’
first problem is imgtool.mak
# add path to imgtool headers
INCPATH += -I$(SRC)/$(TARGET)/tools/imgtool
the standard way to do this would be
# add path to imgtool headers
INCPATH += -I$(MESSSRC)/tools/imgtool
otherwise it will be looking in src/uni/tools/imgtool, which simply doesn’t exist.
but even with that fixed you get a whole load of Windows linker crap, probably because somebody thought it would be a good idea to have a windows specific tool in there.
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x44): undefined reference to `win_get_window_text_utf8(HWND__*, char*, unsigned long long)’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x20d): undefined reference to `win_get_window_text_utf8(HWND__*, char*, unsigned long long)’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x27c): undefined reference to `win_set_window_text_utf8(HWND__*, char const*)’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x39b): undefined reference to `win_get_window_text_utf8(HWND__*, char*, unsigned long long)’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x410): undefined reference to `win_set_window_text_utf8(HWND__*, char const*)’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x5c5): undefined reference to `wstring_from_utf8(char const*)’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x5e8): undefined reference to `osd_free’
obj/windows64/mess/tools/imgtool/windows/opcntrl.o:opcntrl.c:(.text+0x843): undefined reference to `win_set_window_text_utf8(HWND__*, char const*)’
obj/windows64/mess/tools/imgtool/windows/winutils.o:winutils.c:(.text+0x42): undefined reference to `wstring_from_utf8(char const*)’
obj/windows64/mess/tools/imgtool/windows/winutils.o:winutils.c:(.text+0x69): undefined reference to `osd_free’
obj/windows64/mess/tools/imgtool/windows/winutils.o:winutils.c:(.text+0x249): undefined reference to `wstring_from_utf8(char const*)’
obj/windows64/mess/tools/imgtool/windows/winutils.o:winutils.c:(.text+0x2d2): undefined reference to `osd_free’
obj/windows64/mess/tools/imgtool/windows/winutils.o:winutils.c:(.text+0x2de): undefined reference to `wstring_from_utf8(char const*)’
etc.
Compiling MESS first avoids that issue for whatever reason, but as RB has said before, the MESS tools ain’t pretty.
basically it happens because messcore.mak includes some windows specific osd crud (mess/osd/windows) specifically for the MESSUI and Wimgtool.
I’d advocate just stripping it out, Windows specifics shouldn’t be in mess specific makefiles, and Wimgtool is a buggy piece of garbage anyway.
Hi,
I’ve compiled the a UNI build on Kubuntu 11.10 x64. Especially loving the 7zip support, which works fine with MAME, though not so much with MESS. For example ‘uni snes -cart /SNES/Roms/Super Mario World.7z’ will start the SNES driver, but then just stays black, while ‘uni -snes -cart /SNES/Roms/Super Mario World.zip’ works fine, obviously. Is this a known problem?
Thanks for your time and effort
It wasn’t known, a little surprising actually, but I guess the way MESS loads things via filename has some code hardcoded to look for .zip extensions. I tend to use MESS stuff with the software lists, so hadn’t noticed :-)
I’m sure that can be fixed up, I’ll take a look into it shortly.
@Huggybaby:
Concerning Neo Turf Masters:
Take a look at the video emulation code on FBA!