I’ve been playing around with Raiden II some more, and I have come to a startling conclusion: support for Raiden II has regressed. That’s right, the Raiden II driver is currently less functional than it was earlier in the project. It’s still more functional than it was in MAME when we started this project, but it’s quite a good deal worse than it used to be. I have a hunch that the issue is when we re-based to MAME 136, but I need to examine further. I will update this post as I learn more.
UPDATE: I have checked, and the issue is indeed the re-base to 136. I’ll examine the actual diff and attempt to understand where the issue occurred.
I have decided to turn comments back on for now. All comments will be moderated, but this is merely to avoid spam. I won’t censor you guys 
We are working a bit more on Raiden II again now though, and one of austere’s friends is now getting a Raiden II board. Hopefully he’ll motivate us a bit more! As part of my progress on more reverse-engineering, I am working on producing a map of the board, to possibly help figure out just how much the protection handles.
No we aren’t dead. We don’t plan on dying either.
Just informing you, in case you thought we were. When we make some important progress, we’ll post it here for you.
Enjoy the rest of your day/night/etc.
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.
