UME is the complete/combined version of the MAME / MESS project.
I’ve noticed some interest in the Ken Sei Mogura update below, but so far hadn’t got around to posting a binary with support for it. UME 0.153ex5 has support for the aforementioned title (along with a better internal layout from hap) in addition to a number of other things I’ll cover later.
DCS sound system based games (eg. Carnevil, California Speed, NFL Blitz) have been broken since the DCS based Williams Pinball display drivers were improved so I was hoping to see that fixed before issuing a new update, but it hasn’t yet happened; hopefully it will be fixed before there is an official 0.154 release (probably still a month away at least)
0.153ex5 is built from SVN revision 31072
UME 0.153ex5 Windows binaries – 32-bit, 64-bit and all tools
UME 0.153ex5 sources
Here is the 0.153ex4 to 0.153ex5 SVN log
Other Binaries (if you don’t know what these are you don’t need them)
MAME/MESS split 0.153ex5 Windows binaries – 32-bit, 64-bit and all tools
UME/MAME/MESS split 0.153ex5 Windows *SDL* binaries – 32-bit
UME/MAME/MESS split 0.153ex5 Windows *SDL* binaries – 64-bit
Points of Interest
We’ve seen a number of prototypes show up over the last few years, some of them early builds, some of them almost indistinguishable from the final versions of the game. Another one so far falling into the latter category is a Raiden Fighters SPI Cartridge. ‘Karen’ found this version of Raiden Fighters and it displays an interesting message on the title screen ‘EVALUATION SOFTWARE FOR SHOW LICENSEE TUNING – GERMANY’. This message is present in the ROMs for all versions of the game, however it isn’t usually used. We know TUNING licensed a lot of Seibu’s games (including the Raiden Fighters games) for use in Germany, so it makes sense that them might have been sent preview versions. What makes a little less sense is that the board is an Australian region board (according to the region byte) and was found in Australia.
It would be easy to write it off as some kind of hoax / hack, but the actual codebase is clearly a different revision than any of the previously supported sets at least, so it’s definietly not a cheap hack of a set we already know about, and could actually be earlier code, although so far we’ve been unable to identify any actual differences in the gameplay so it’s probably close to the final, or maybe even a later revision than those used in Japan if it was sent for evaluation after the actual Japanese release. I do hope somebody attempts to identify all the differences in the various Seibu revisions one day because most of their games have a number of builds.
Along similar lines what appears to be a ‘close to final’ US / World revision of Galaga 88 was found / dumped by Andrew Welburn. There are only a few differences between the ROMs found on this PCB and the final PCB but all the ROMs were hand-dated and in one of the graphics sockets there was an extra rom containing only the fonts and a few other characters – it has the earliest date and is probably a leftover from an earlier point in development because the game doesn’t seem to use it.
An early revision of Peek-A-Boo was also dumped. The ROMs on this one were marked as ‘Version 1.0’ and the title screen indicates that it’s a US set. Furthermore the game seems to be a ‘Paddle Only’ version because enabling the dipswitch for ‘Button’ mode causes the game to enter a debug menu after a few seconds. (This needs further investigation tho)
— early Joust 2
— early Knights of Valour Super Heroes
One fix that is likely to be overlooked by the majority is the one made to the Amiga emulation allowing the Arcadia game Space Ranger to function correctly. Space Ranger has been marked as ‘Working’ in MAME for a long time, but was another case of a driver being marked as working prematurely. To play the game you need 2 buttons, and for the majority of Arcadia games both buttons worked, however in Space Ranger the 2nd button didn’t, meaning you couldn’t use the net to capture / rescue the creatures along the bottom. It turned out to be an issue with the emulation of an internal timer, so hopefully the fix has also improved some Amiga titles where inputs weren’t responding correctly. Along with coming up with this fix Duke has also continued to improve other areas of the Amiga emulation although it still struggles with most copy protected software.
The steady flow of Spanish versions of games continues, this time with a professionally made (possibly licensed) version of Space Invaders from Electromar. This has all the texts translated and even has a nice touch in that the Invader steals the ‘M’ of ‘FIM’ and replaces it with ‘N’ as opposed to replacing an inverted ‘Y’ of ‘PLAY’ in the regular versions. You can thank Roselson of AUMAP for finding this one.
Another interesting finding was made when Artemio dumped his 2 Crude Dude board. Quite often when people dump boards they take a rather lazy approach of dumping only the program roms, even in cases where other roms are socketed. What Artemio found is that later revisions of 2 Crude Dudes are meant to use an updated tile rom, with some changes to the Japanese characters. His actual board was a US version so these tiles are unlikely to be used on it, but after looking at some photos it appears the later Japanese versions should also use this revised rom and were not doing so.
I mentioned hap improved the Kensei Mogura internal layout a bit, this is how it looks now
– Sinclair QL work
– x68K blending work + other fixes
– Konami cleanups
– More MSX improvements
– Better Namco System 1 memory maps
One from the ‘requested at a timely moment’ department is the fix made to Super Volleyball. A number of gameplay elements were missing, such as marker arrows, player hints and the confetti after scoring. The fix was actually simple, the bug was caused by an incorrect loading of the sprite roms, meaning it WAS drawing those elements, just with blank tiles. Fixing it turned out to be nice and easy. I don’t know if it’s always been like this, or regressed during other cleanups. Fixed now anyway.
The recent work by Roberto caught my eye too, we’ve known for a long time that there were some other ‘games’ on Cherry Master hardware and his most recent update shows emulation of two of them. Tetris and Pacman.
Now you’re not going to want to actually play either of those. The Tetris version is criminally boring, the playfield is so wide you’ll have hit the quit button long before you’ve filled a line and the aspect ratio is just odd. Pacman isn’t much better, on my first play I managed to glitch the game so that one of the fruit items was stuck on the screen, couldn’t be collected, and wouldn’t disappear, furthermore the ghosts tend to move mostly at random but usually end up simply blocking your access to the power dots by congregating around those areas. Don’t expect smooth movement on the games either, the hardware has no sprites, only tilemaps.
The reason these existed was not so they could be played, the games are just facades, as Roberto mentions they simply hide Cherry Master games behind an innocent looking exterior. This worked in a similar way to the drugs trade, these Cherry Master games were banned in various places, so importing / exporting them wasn’t allowed, and if you were found to be operating them you’d have your boards seized / destroyed as well as being handed large fines or worse. By hiding them behind a more innocent looking game (even if said innocent looking games were probably just as illegal with all the ripped art assets) these games could be operated with greater secrecy, and switched between titles with a secret operator input if needs be. I’m glad to see these dumped / emulated because we’ve seen the same things but with physical protections too, for example light sensors so that if the cpu boxes were opened to inspect the games the content was erased – needless to say between boards being seized and the kind of physical protection I mentioned some of them are rather rare now, but it’s part of history that needs documenting.
Some of the most important work done on the arcade side of things over the last few weeks has been a number of the devs putting in some hours to figure out decryption keys for a number of Sega FD1094 based games where we didn’t have the CPU modules, or the modules we had were already dead. This isn’t easy work because although the basic structure of the keys can be generated from a seed there are areas of them were customized in each CPU and working these out requires extensive studying of the code between sets. Andreas Naive and Chris Hardy were the ones doing this work, with hap acting in a supporting role to hook up driver level differences between the games. For the most part this isn’t especially rewarding work as the clones often only differ by the encryption types used, however it’s important work and in some cases subtle differences can be seen. Out of the various sets that were decrypted the System 16B version of Ace Attacker was the most interesting, it required the controls hooked up in a different way, and also interestingly uses a different font for the ‘Insert Coin’ text with an actual graphic being used where the System 16A version just used ordinary text.
(more soon)
Haze, can you able to add Mr. Bison’s Face on each buttons on that layer?
Much better to reconize the original Machine.
Somebody could create external artwork with such things on, the idea of the internal artwork is that it represents enough of the game without risking infringing any copyright on the artwork.
Better be glad those are Mr. Bison heads not private part popping in and out. LOL
Thanks for the info Haze. It could be fun doing that, get’s more attractive. I don´t know if possible to transform Mr.Bison’s Head in 3D, using Blender or AutoDesk and make it work on MAME :D
Accurate 3D models can be actually created by just scanning the pieces with a Kinect, but there doesn’t seem to be much interest on such things at the moment…
I’d love to see a proof of concept for this kind of thing !
Even if the 3D models were made (and please correct me if I’m wrong), I don’t think MAME/MESS can currently display any 3D imagery as it does with the 2D artwork.
I’m guessing that, if it could be done already, somebody would have tried to recreate at least one pinball table at this point (not talking about making it playable, but at least the external appearance with a working attract mode).
When I said proof of concept I was actually talking about someone coming up with the first lines of code to support that kind of experimentation with 3D artwork… Regarding potential copyright infringement I would start with crude cylinders going up & down supported natively in MAME, while more detailed 3D models from external artwork files could be loaded optionally by the users.
I see you are also sharing SDL builds for Windows. I thank you for this. My frontend Emu Loader now supports SDLMAME for Windows :)
Thank you for the updated MAME builds. You’re continuing work in MAME is really appreciated.
Yeah, I’ve seen a few people ask about them lately and there were some recent fixes so I quickly put them up, remembered now I forgot to strip the source from those packages, but nevermind.
I left them in the experimental section because I’m not 100% convinced by the SDL experience on Windows, there are definitely a few niggles (the location it chooses to open new windows upon launch is often partially off-screen, you can’t ctrl-c quit from the command prompt if the debugger is open, and there seems to be more audio-breakup and audio-lag, and the default renderer sucks, you need to specify -video opengl) but I guess a few people might appreciate the added flexibility of GLSL (although from what I’ve read it fails on games with dynamic resolution changes) and be interested in seeing the state of it in general (the QT based debugger etc.)
I’ve noticed similar ‘issues’ with other SDL applications too tho, so it might not even be something that can be improved on Windows.
I don´t know nothing, but i’m sure someday Mame must be transformed in to a 3D Dimension. Now we can play Arcade Machines in 3D, like we are in a Store.
Here is one example: https://www.youtube.com/watch?v=qfmN8PJkLTc
How fun can be Mame like this?
This game is to make the underwear in a violence explosion
From what I could test, some GLSL shaders are pretty sweet.
Hmmmn, I get a “Unable to compile shader (unspecified reason)” error when I run a game in Mame 0.153 ex5 64bit with HLSL enabled, works fine with HLSL off. The official Mame sites 0.153 64 works fine with HLSL enabled.
Exception at EIP=00000000015DCF77 (d3d::shaders::delete_resources(bool)+0x0197): While attempting to read memory at 000000000000000
I can only reproduce that if I delete the hlsl folder (or change the path to point somewhere invalid)
any further information on what you’re doing?
I just did a clean install of ex5 (default settings except for HLSL enabled) and that message came up. I think I’ve isolated the problem to be with Emu Loader 7.6.3, I think it’s altering the hlslpath hlsl in mame.ini to say hlslpath “then nothing” by default. Anyway, it’s fixed now. Thanks for your help there and for doing the different builds. Love your work, Haze.
I will investigate this problem with Emu Loader. I’ll test with UMEux5, MAMEux5 and the latest official MAME release.
I found the problem. Some .ini settings now have “auto” in them (UME.153ex4 and ex5) but official MAME .153 still use integer numbers (mame.ini)
Entry ‘sound’ is one of them. It has ‘auto’ now and Emu Loader can only handle integer values in it.
Another entry ‘video’. The default value is ‘auto’ now, but it used to be d3d.
I need to update Emu Loader as soon as possible.
Haze, I think you know the reason why I didn’t compile MESS no more for myself.
Did you you tried the “-ab” autoboot command
(LUA script) on your compiled MESS/UME 32-bit binaries?
OK, no need further discussions about the LUA script.
Tafoid wrote:
“Anna: Correct Lua scripting for the most part is broken at the moment. It will be a while before it is fixed.”
Thanks Tafoid for the info!
Emu Loader updated to support ex5 builds (Win and SDL) :)
Good to know. That should mean you’re better prepared for 0.154 too, because I imagine they’ll stick and once 0.154 is released a lot more people will be exposed to them.
We can’t do 3D models right now, although there are definitely some things that would benefit from full cabinet simulations (where they use physical mirrors etc. to place things at different positions / give 3d effects)
It’s worth people collecting things, creating HQ resources etc. because maybe one day there will be demand for them but like everything it’s a case of somebody special needing to do something in a way everybody agrees with. (and there are many things to consider, eg. does it include a physics model for advanced cabinet simlatuions or would it be a purely artistic / visual feature with fancy shaders doing mirrors etc.)
yeah, lots of underlying changes going on at the moment, although I guess there’s a chance if the code changes enough it might start working again in your own compiles once everything is done ;-)
Sorry to butt-in, but is there any timeline for migration to SDL2?
I believe the code is quite stable now and receives almost daily attention from Sam and others.
I believe he has fixed a lot of the issues with the windowing and other behaviour that you mention.
I get this error when I exit Mame 0.153ex5 64bit after playing R-Type II. Either with HLSL on or off.
D:\Emulation\Mame>mame64 rtype2
Average speed: 100.00% (40 seconds)
Error: attempt to free untracked memory 0000000004B02080 in (null)(0)!
0000000008D1F100: 00000000015C2ADE (winmain_dump_stack()+0x003e)
0000000008D1F1C0: 0000000002433E94 (osd_break_into_debugger(char const*)+0x002
4)
0000000008D1F230: 00000000022598A4 (free_file_line(void*, char const*, int, bo
ol)+0x01c4)
0000000008D1F2F0: 00000000015D95E5 (d3d::shaders::~shaders()+0x0065)
0000000008D1F3A0: 00000000015E7486 (d3d::renderer::device_delete()+0x0076)
0000000008D1F440: 00000000015E76B2 (drawd3d_window_destroy(win_window_info*)+0
x0082)
0000000008D1F530: 00000000015D0FAE (winwindow_video_window_proc(HWND__*, unsig
ned int, unsigned long long, long long)+0x061e)
0000000008D1F560: 00000000015E602D (winwindow_video_window_proc_ui(HWND__*, un
signed int, unsigned long long, long long)+0x000d)
0000000008D1F620: 0000000077A69BD1 (TranslateMessageEx+0x02a1)
0000000008D1F670: 0000000077A63BFC (CallWindowProcW+0x009c)
0000000008D1F6B0: 0000000077A63B78 (CallWindowProcW+0x0018)
0000000008D1F720: 000007FEEFD035D3 (Direct3DShaderValidatorCreate9+0x58f7)
0000000008D1F7E0: 0000000077A69BD1 (TranslateMessageEx+0x02a1)
0000000008D1F840: 0000000077A672CB (SetWindowTextW+0x0277)
0000000008D1F8A0: 0000000077A66829 (IsDialogMessageW+0x0169)
0000000008D1F928: 0000000077CC11F5 (KiUserCallbackDispatcher+0x001f)
0000000008D1F930: 0000000077A5CBFA (DestroyWindow+0x000a)
0000000008D1FA20: 00000000015D0E21 (winwindow_video_window_proc(HWND__*, unsig
ned int, unsigned long long, long long)+0x0491)
0000000008D1FA50: 00000000015E602D (winwindow_video_window_proc_ui(HWND__*, un
signed int, unsigned long long, long long)+0x000d)
0000000008D1FB10: 0000000077A69BD1 (TranslateMessageEx+0x02a1)
0000000008D1FB60: 0000000077A63BFC (CallWindowProcW+0x009c)
0000000008D1FBA0: 0000000077A63B78 (CallWindowProcW+0x0018)
0000000008D1FC10: 000007FEEFD035D3 (Direct3DShaderValidatorCreate9+0x58f7)
0000000008D1FCD0: 0000000077A69BD1 (TranslateMessageEx+0x02a1)
0000000008D1FD30: 0000000077A672CB (SetWindowTextW+0x0277)
0000000008D1FD90: 0000000077A66829 (IsDialogMessageW+0x0169)
0000000008D1FE18: 0000000077CC11F5 (KiUserCallbackDispatcher+0x001f)
0000000008D1FE20: 0000000077A69E6A (SfmDxSetSwapChainStats+0x001a)
0000000008D1FE50: 0000000077A69E9E (GetMessageW+0x002a)
0000000008D1FEF0: 00000000015CF53E (thread_entry(void*)+0x007e)
0000000008D1FF20: 000007FEFF81415F (srand+0x0093)
0000000008D1FF50: 000007FEFF816EBD (ftime64_s+0x01dd)
0000000008D1FF80: 0000000077B659ED (BaseThreadInitThunk+0x000d)
0000000008D1FFD0: 0000000077C9C541 (RtlUserThreadStart+0x0021)
— memory leak warning —
#008137, nofree 1344 bytes (src/osd/windows/d3dhlsl.c:734)
a total of 1344 bytes were not freed
D:\Emulation\Mame>
I’m not seeing this at all, is it with cheats or something?
I don’t know what happened exactly, but after making a new mame.ini, it’s stopped the error message from occurring. 8^/
I didn’t have cheats enabled.
I think I know what causes the problem now, it occurrs when you have “hlsl_preset” set to anything other than “-1”.
This occurs with HLSL on or off.
ok, I can confirm that.. wonder if it’s recent cli changes, or if it’s been happening for a while.
I’m not sure what the plans are, I guess it will happen eventually (afaik it’s needed for better multi-input/output support anyway)
SDL2 is likely to become the default early next year and you can enable it now if you’re curious, but be warned that SDL2 itself is rough (particularly on OS X), and MAME’s support for it is even rougher, so we don’t support those builds in any way yet.
I expect things will have smoothed out enough to make it a viable end user default late this year (once Fedora 21, Ubuntu 14.10, and SDL2 2.0.4+ have shipped).
It is good to see Super Volleyball finally 100% emulated,I love that game,it was playable but harder in a way you couldn´t tell where the ball was going to hit…
And it´s a nice touch to see that whackamole SF game,I clearly remember seeing that game at an arcade in Mar del Plata(seaside city in Argentina)it was put together beside kiddie games,I´d loved to play it but I´d look ridiculous…hope you understand my bad English…
Haze how about Primal Rage II?
I heard people telling this board have a lot of protections.
I wish can able to test this game on mame.
“That “0.36a number” tell me nothing to be a alpha or a beta game”
It’s so completed.
Haze you don´t need.
Maybe in the future, new people will do it.
It is OK now from the newer SVN source. Made the build this morning. :)
K:\UME>mame64 rtype2
Average speed: 100.00% (63 seconds)
K:\UME>pause
Press any key to continue . . .
The kinst driver is outputting a memory leak warning:
— memory leak warning —
#013552, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013489, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013521, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013494, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013562, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013525, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013608, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013565, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013618, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013549, nofree 144 bytes (src/lib/util/coretmpl.h:404)
#013511, nofree 144 bytes (src/lib/util/coretmpl.h:404)
a total of 1584 bytes were not freed
Those people are, as far as I know, incorrect. There is no obvious protection whatsoever, just typical late-period Atari coding.
The game used to boot and run some of the attract mode. You can go back to the version before Turret Tower was enabled and see.
Well in mame 0.150 only freezes in the select char. I can´t even play it.
I think it was mentioned that there’s an Altera PLD on there that could be acting as some kind of basic protection, although it wouldn’t surprise me if the disk geometry was just wrong or something given the stupid stuff we’ve seen in the past.
I wonder if anybody has tested the CHD we have in MAME on a real drive.
the reported issue is when using -hlsl_preset 2 (or something ‘invalid’ along those lines)
Yes Haze i have the CHD, and i already test it.
The first Read will give you a black screen.
The Secound time if we reset the game will give you a “WatchDog Reset” and continues to get black screen.
And i try to run by selecting the CHD on the menu Tab, and gives a error and tell me it have already the CHD Read.
Size: 524MB – 549.781.704 bytes
primrag2 0000000 ide:0:hdd:image
In the Audit options it have this…
primrag2 : upd78081.655 (8192 bytes) – NOT FOUND – NO GOOD DUMP KNOWN
Is that the same Tuning responsible for Bubble 2000?
yeah, I think they were the importer / licensee for Afega too.
Oh OK. I just saw on or off. So thought it was the game itself is doing that.
By the way. I saw the memory leak warning a few times when I use the command lines. On some of the MESS systems. I haven’t seen the warning in a while.
Note: Don’t use any of the shaders with the sdlmess64 genesis or megadriv or megadrij. R. Belmont point it out there is a screen issue on this. Leave the GLSL settings turn off when running this. What is happening is the screen doesn’t scale right. Go out of bounce which causes graphics corruption and the resizing. There is no screen issue when it is turn off. :)
Oh one more thing.
gl_forcepow2texture 1
This will fix the nes and neogeo screen issue.
R. Belmont “There are known problems with games that change resolutions (e.g. if you let Sonic 2 go into 2 player split-screen you’ll be missing half the screen afterwards).”
that’s an MCU internal rom on the zn motherboard for analog controls, most games don’t use it
ok happpp.
Anonymous: he means writing the CHD to a physical harddrive and trying it on a real Primal Rage II board. We are aware of how it (mal)functions in MAME :)
You should *never* enable that option on a video card made after 2002, my GTX 780 shows NES and NeoGeo fine with it off.
Thanks Arbee, i was thinking later about this, and that is your correct answer.
Please if possible on mame 0.154 a working version of this game.
it’s very unlikely it will be working any time soon, I don’t think anybody with the knowledge to even attempt to fix it is actually looking at it.
Now that the Saturn CD ROM is dumped, does this have any implications for Saturn emulation in MESS, or is something else holding it up?
it’s good news, because the CD block HLE is a complex mess of guesses.
it might improve compatibility a bit, but the main end-user effect will be the driver becoming slower, because it’s yet another CPU to emulate and likely have to keep in perfect sync with other devices!
I will pray for that haze.
SH-1 won’t require perfect sync, but yes it will likely make the driver slower even as it improves some compatibility corner cases.
That said, the CD block isn’t really the main problem with the driver, the graphics rendering is.
graphic rendering and timing issues, unfortunately due to the complexity of the system getting the subtleties of the timing right is a nightmare, there seems to be stuff that issues vdp draw commands THEN uploads some of the sprite tiles, because they know the vdp1 won’t have actually drawn that image before the sh2 has uploaded the data for it, unless I’m misdiagnosing the problem.
(and of course on the MAME side, the remaining protections, which are some kind of Naomi style encryption stream)
Thanks a million for Super Volleyball, it always been that way as long as I remember, and I’ve been into Mame (and into Super Volleyball as well) for a looooong time.
I am actually happy i requested this easy fix at the right moment :-)
Just awaiting for .154 so that my beloved Groovymame gets updated. Thanks again mate !