I’ve just acquired another PCB on behalf of the project. I’m currently in Hong Kong and I’m trying to get time in a “chip characterisation laboratory”. I have confirmed that I can get help decapping some of the chips. More news to come.
2010/11/26
2010/11/01
Just Something To Share
http://www.youtube.com/watch?v=4M5xt61WDrs
Not anything really Raiden II related, just wanted to share :3
2010/09/19
… Regression
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.
2010/09/18
Comments
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.
2010/08/28
Not Dead
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.
2010/07/23
Binaries
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.
Command Line Arguments
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!
2010/07/22
Lagless MAME
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!
2010/06/11
Change Backporting
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!
)
2010/06/06
Welcoming Homebrew and Contributors
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.
