Due to popular demand, we’ve made binaries available of the latest build. You can download them here. Not all builds will have the debug-enabled MAME executable due to some toolchain issues.
Please remember that UberMAME uses different command line arguments to regular MAME, so some configuration will be necessary. See the previous post for more detail and have fun!
UPDATE: Included SDL.dll in the win32 package.
Yesterday I brought up the topic of the command line option syntax with austere, noting how MAME used -switch, instead of the standard --switch. We both decided that since UberMAME is still not very widely used, it would be a good time to fix the syntax. Earlier today I pushed up a change that now uses the standard switch syntax, and cleans up a lot of the names of the options. An example of the change would be our switch for Lagless patches, which was originally -lagless, is now --lagless; turning lagless off was originally -nolagless, and is now --no-lagless. We also changed the names of several switches to cleaner versions. An example is -showusage, which is now --show-usage.
One of the biggest side-effects of these changes is that old mame.ini files are now completely invalid. You should make a back-up of your old mame.ini, use mame --cc to make a new mame.ini, then copy your changes back (don’t change the option names though!) and you should have a working mame.ini again.
Hoping that these changes will be pushed back upstream, but if not, oh well.
Another change that is worth noting is that we have removed the Windows OSD. No, this does not mean it won’t work under Windows, it just means that you will be using the SDL OSD, which will be actively maintained by us, since the majority of development from us comes from *NIX computers, which won’t build the Windows OSD. There shouldn’t be any substantial performance hits from this decision, but it’s a good thing to note.
Happy hacking!
UPDATE: I cleaned up the post a bit, apparently the double-dashes looked like single dashes!
Earlier today I applied our good friend nimitz’ patches for MAME that he called Lagless MAME. Instead of being on all the time, we have made them switchable with the command-line flags -lagless and -nolagless, which turn on and off lagless patches respectively. The default is for the patches to be off. The Git repo has the latest version as always.
Another bit of concern is binaries. I have had a few requests for binaries, and I’d like to see how many people think that binaries are appropriate at this stage of development. As usual, comments on the BBS please.
Enjoy, and have a good night!
I have finally begun back-porting changes from newer versions of MAME into UberMAME. I am starting off with 136, which makes a bunch of changes for re-entrancy and some better game support. This process isn’t too difficult yet, since UberMAME is not significantly different from newer versions yet, but I can imagine back-porting from 137 and 138 will be a bit more difficult than 136.
In somewhat related news, Giles had been converting a bunch of code from macros to C++ templates in his terrible attempt to convert MAME to C++ (why do this, I have no idea) . This greatly slowed compile and link times. However, apparently Giles reverted a bunch of those changes, in reaction to complaints from other MAMEdev. I knew I was right 
UPDATE: Changes from MAME 136 have been integrated into UberMAME, and are now available on the Git repository. Enjoy! Also, EEPROMs are no longer required, they are optional. I have also made it not require ROMs to load, but if it is missing, it will warn, but attempt to play anyways (good luck with that! )
I’d like to make sure that it is clear that I welcome anyone who wishes to contribute any changes at all to UberMAME. Anything at all, from driver fixes, to core changes, or to just adding a new rom-set, we will review and possibly add to UberMAME if we feel it is helpful (simple changes like re-doing code-style without adding functionality, or senseless renaming of rom-sets [We will accept rom-set renaming if it has a reason though]). If you submit enough changes, we will consider adding you to the project on GitHub, so your patches don’t have to be screened (it means we trust you enough to handle our repository. If you do anything to cause us to lose our trust, such as sabotaging the code, you will promptly be removed.)
Another point I’d like to make clear is, we are allowing any entries for homebrew rom-sets. So if you just made a kick-ass game for PGM, and want to see it in UberMAME, go ahead and tell us, we’d be glad to add your rom-set. I felt that after adding my Seicop tester to UberMAME, I should allow any homebrew code, not just my own.
So yeah, if you want to contribute, or submit your own rom-sets, or really anything at all, go ahead and hit me up at trap15@raidenii.net, or on the BBS. 
The last 2 days or so I’ve been looking at the PGM emulation, specifically DoDonPachi II. If you currently run DDP2 in UberMAME it will die with an error “Unhandled Coprocessor 13″ or such. This is because the internal ROM for the DDP2 protection (ASIC27a) is currently undumped. I have written a small “replacement ROM” that goes in the file that would hold the dump. All it does is an infinite loop, so it’s not actually handling any protection, it just allows the game to be (somewhat) played.
According to comments in the pgm.c code, the internal ROM for the ASIC27a should be dumpable, but it hasn’t been yet. I’ve sent a question related to this to MAMEdev, so I’ll be sure to let you all know about any updates to that. Aside from that, there were a few bugs in the PGM code which I have fixed (fixes some graphical glitches), but there are still some mysterious graphics glitches that I need to investigate further.
The game does run currently, and at a playable speed, but the game is not really playable. I say this because all bullet handling is performed by the ASIC27a, so the only bullets that actually work are the players. I’d presume this is because they offloaded all the work from 68k in the PGM to the ASIC27a on-cart, so the 68k could be used for everything else (since from what I’ve seen, DDP2 has a good lot of bullets, and there would be significant slowdown if everything was handled 68k side)
I’m probably dropping off of PGM for a bit soon, as my friend almost has all the stuff we need for our supergun, so I can begin hardware tests for Raiden II.
UPDATE: Haze has said that it is indeed dumpable, but it being dumped isn’t “high priority” right now, and other PGM games that need their ASIC27a’s dumped will probably be done first. So, just give it a while
(Via BBS post at http://raidenii.net/bbs/kareha.pl/1275574528/l50)
Our domain at http://www.raidenii.net/ is now functional, so please update your bookmarks if necessary.
Over the last few days I have been working on the UML and SH-2 cores, as outlined in this BBS post. I finally fixed the cores how I wanted them fixed, so they work all good now. Basically, I modified the basic include file for the UML to define which UML core to use (since before it relied on the build-system), and then fixed the SH-2 interpreter core (it had suffered some code rot since it hadn’t been used for a while) enough to run on it’s own. Then I modified the SH-2 header to check if UML was using the dynarec or the interpreter core, and if it found interpreter, it would drop back and use it’s own interpreter for extra speed. I plan on doing this to as-many-as-possible/all of the dynarec cores so that there is a bit of speed improvement on non-dynarec systems.
On a related note, a good friend of mine recently had his family give him their old PowerPC Mac Mini, so he decided to give it to me, since he knew I’d make better use of it than he would. This means I now have a (slow) PowerPC machine to test on, and may write a PPC dynarec UML core eventually.
I’ve also considered making full builds of UberMAME available for download every once in a while (when we feel we have made big enough changes that a build would be a good idea), since I single-handedly have all 3 major OSs.
Any questions or comments should go on the BBS, which you can find a link to on your right-hand side. Happy hacking!
The Raiden II Project now has an official BBS! The BBS runs on Kareha, which is a robust BBS system written in Perl. You can discuss anything on there, just try to keep it related to UberMAME or Raiden II Project. You can get to it at http://www.raidenii.net/bbs/. Have fun!
Lately I’ve been working on our trojan for the Raiden II board. Support for the trojan is in the latest UberMAME commits, under the name seicop. That name comes from what it does, it probes the SEIbu COPx-d2. It’s not specifically different from the Raiden II driver, the only change is how it handles the loading of the program ROMs (on Raiden II it has 2 interlaced ROMs. By interlaced, I mean, one ROM has the even bytes, the other has the odd bytes. The seicop driver merely changes this to be a single ROM with no modification.). Also, somewhat interesting to note, it appears MAME doesn’t fully reset the system, as the trojan currently keeps its state completely intact after hitting reset. Well, aside from the state of the sound CPU. Anyways, I’m a bit off topic, back to stuff about the trojan. The name of the trojan is COPper (interpret that either as the metal copper, or a policeman copper, but make sure you pronounce it like that!) and is written completely in V30 assembler (V30 is just NECs take on the 8086, nothing really of note there) and the code currently takes a mere 301 bytes! At present it contains a full setup for 12 different modes of operation, with 3 of them currently defined.
We have mode 1 for Memory Viewing. It allows you to view the first 0×20000 bytes in a nice easy format. Mode 2 is for Memory Writing. It will support writing an arbitrary amount of data in sequence, for things that require quick multiple modifications. As you could probably tell, mode 2 isn’t done yet. Mode 3 is a BGM music box (it’s actually mapped to the last mode, mode 12) that plays all the games background music (actually, if you replace the sound data, you can get your own music, but they have to have the same music indices).
This trojan should eventually be able to test most, if not all, the features of the Raiden II board. Specifically the COPX-D2, but it will probably test other parts too.
If you have any questions, comments, concerns, etc., please post a comment, and we’ll get back to you ASAP
Powered by WordPress