Please post any fixes/changes/etc. you would like to see implemented in UberMAME in the future. This could be critical bugs in 135 (regressions, speed issues, etc.), or things you'd like to see (better support for PGM, etc.).
No ideas are stupid, and requests for newer games (Ketsui, etc.) are allowed (although, they may not be as possible as we'd like :P)
Thanks,
UberMAME Team
Hmmm, that's something that PsikyoFan could probably help us out with.
Yeah, most probably. I've been thinking of doing a bunch of DIFFs from each MAME revision since 124 to 135, just to see all the changes. That way we can have a bit easier time fixing regressions/adding newer features (for versions newer than 135, we can still get all those new drivers working, since apparently most people still write the drivers in C :P)
Fix audio in Taito G-net
Fix the Konami GX games so we can finally play the great Parodius series i nfull glory!! :)
>>9
Not yet!
Sexy Parodius is missing a lot of transparencies, like the stained glass of the mice mansion stage (also that level has missing background). Also Gokujou Parodius has a few glitches too here and there (the intro, possibly the water level, etc).
The whole driver is still marked with inaccurate video emulation and some games have protection problems.
>>10
Huh, I was completely unaware of that! We'll look into it later :)
Thanks! :)
Will they get included into the officla MAME build?
>>12
Depends if MAMEdev want the fixes :P They probably will; in which case, yes they will.
Ok. Good luck! :)
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.
All comments or concerns welcome.
Temporary list of DDP2 Glitches and which graphic mode the error occurs in:
There occurs random garbage on the text-screen as soon as DDP2 loads, pgm_tx_tilemap.
Random column offsets that shouldn't exist (usually 1 or 2, offset by maybe 1/4th the screen-size.) in the Background layer, pgm_bg_tilemap
Random masking out and glitching of unknown graphics layers (!?)
I will probably find more. If you find any, please add to the list
The random masking and glitching appears in the sprite layer. This is very intriguing, as I am not sure what precisely could even cause this.
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 :)
How about that PGM. :P
So, as most of you know, the STGT 2010 is coming up. I've discussed this idea plenty on the IRC channel, but I'd like to start a team with our members. You have to be on IRC, so we can discuss whatever, so drop by #raidenii on EFnet! The purpose of this thread is for you to tell us you're going to join the team, so we have a solid place of who is going to play. There's a minimum of 5 players, and a maximum of 7, so it's first-come first-served.
How do I shot web?
O SHI-
SIGN ME UP
You suck Ransom :( you betrayed me! ;_;
i'm in
Consider me in!
I've put our current team up on the thread, but we're still lacking 2 people!
LtC and noaliens are in, so we now have enough people! :D
I have dropped MAME OS X support for UberMAME. This decision has been made after realizing that the Xcode build system sucks cocks. No, this does not mean we will be switching over to 138 or whatever, it just means I won't have to deal with MAME OS X's crap anymore. It also means that I am now including SDLMAME by default in UberMAME. This fixes tons of headaches I had with MAME, just because of the stupid build system. It also means dynarec support should work with all our builds since the default MAME build system works with it :P
Happy hacking
Remind me to write up a procedure for compiling windows binaries.
Give any information for rom-sets or any other additions to UberMAME you would like to submit here, or email them to trap15@raidenii.net.
Thanks
So, one of the questions I had going into starting UberMAME was: why are Psikyo SH2 games so damn slow on 135, but perfectly fine on 124?
Today, in my usual boredom, I decided to finally take a look. I fired up Instruments.app and starting doing a CPU profiling while I (slowly) played Gunbird 2. After running it for a bit, I exited MAME and looked at the logs. I was appalled. A single sub was taking 88% of the total execution time. Yes, that's right, 88 fucking percent.
I dove into this unknown sub, drcbec_execute and examined it. What I saw made me laugh my ass off. drcbec_execute is the main sub for MAME's UML, Universal Machine Language. UML was meant to simplify dynarec, so it wouldn't be platform specific. You would expect that their UML core would, you know, actually be dynarec. It's not. It's slow, takes huge amounts of UML code to do anything useful, and most of all, is slow.
This is why Psikyo SH2 is so slow. And it doesn't just apply to Psikyo SH2, it's every single dynarec core.
So... questions about it? Comments?
We do plan on doing something to fix this mess. Maybe not now, but in the future, this will change.
Don't forget to check out line 446, 476 onwards of that same file ... :p
Alright, I have (hackily) fixed the SH-2 core by making it use the interpreter again. Haze says there's an actual dynarec version of UML in there, it just isn't enabled for us for some reason. I've pushed the interpreter version of the SH-2 for now, I'll fix the UML stuff soon.
Alright, party time! I fixed the UML garbage. It seems anyone who isn't building with MAME OS X had the UML working fine, since the problem arises in the build-system. I added a nice little kludge into the code that makes it not rely on the build-system for that info. Also, I made it so that if the SH-2 core can't find a dynarec UML core, it will go ahead and use it's own interpreter, to speed it up a good amount. The native interpreter still isn't nearly as fast as the dynarec though (SH-2 interpreter gets 150% for me, whereas the dynarec core gets 600%)
Go ahead and build the latest commit if you want to try it out :)
Welcome to the Raiden II Project BBS. Enjoy your stay. :)