The last posted fixes were, unfortunately, not perfect. Some games have regressed (notably gunnail). I apologize for this failure on my part, and I hope for your forgiveness.
Anyhow, I have fixed my fixes (>_>) and marked games that are still broken as Imperfect Graphics (do not be confused; my changes no longer are regressions on other games, I am simply marking them as they should be). You may notice that Rapid Hero appears to be regressed, but it is more accurate (it features the same sprite address twiddling as Thunder Dragon 2). (EDIT: Rapid Hero is fine, I just suck at testing) There are still issues with priorities that are unknown, and need to be fixed. You can notice them in many games, unfortunately.
This patch can be applied to the current version of MAME.
Sorry about the downtime, we upgraded the server we were using, and during the upgrade we went from MySQL 6.x back to 5.x (as recommended by the MySQL team), and that broke a bunch of tables we were using because they apparently changed some collation IDs. Anyways, we finally were able to fix the tables, so everything’s back up!
Wow, it’s really been almost a year since the last post here. Sorry for the lack of updates, there’s just not really that much going on.
Anyways, recently I got shown NMK’s Thunder Dragon 2, and I really enjoyed it. Really enjoyed it. But I noticed that the sprite priorities were fucked up! I thought this was just NMK being NMK, so I did a quick ROM hack to fix them up, which worked well. I checked with others after though, and apparently they were not fucked up on a real board. I asked around, and thankfully Dave_K had a board (a bunch of other NMK boards too apparently), so I started attempting to fix the driver with his help. Eventually I figured out the prioritization method that the video hardware uses (which, frankly, is fucked up to hell), and fixed the video driver up to use it. The games that are affected by my patch are:
mustang
mustangb
vandyke
vandykeb
acrobatm
tdragonb
ssmissin
macross
blkheart
twinactn
tharrier (not fixed, but it shouldn’t be hard to fix from what I have changed it to)
hachamf (not fixed, but it shouldn’t be hard to fix from what I have changed it to)
tdragon (not fixed, but it shouldn’t be hard to fix from what I have changed it to)
gunnail
macross2
tdragon2
raphero
It is possible that more sets could utilize my improvements, but these are the ones which I have fixed and verified.
I have recently re-installed Linux, this time with Arch instead of Debian, onto my old Mac Mini G4, as well as setting up SSH for X tunneling and such. This means I can now easily work on anything on my PowerPC machine from anywhere with an internet connection (it also means I can keep my dual-monitor setup, since I can just tunnel in from my regular machine).
Thanks to this wonderful advancement, I can now start working on a dynarec core for PowerPC. This will likely be a long arduous task, but it’s well worth it, in that 32bit PowerPC machines (and maybe 64bit ones as well?) will be able to run MAME with far better performance on newer games.
Before I go, here are some quick benchmarks:
Game
Raw interpreter
UML interpreter
Gunbird 2
58%
24%
Strikers 1945 II
56%
22%
Avengers in Galactic Storm
63%
112%
Cyvern
38%
73%
By the end of this, I should have 100% at the least for these games!
In MAME 0.141, Virtua Bowling (vbowl) will crash upon startup. This is due to austere not completely fixing the igs011.c driver after he did a bunch of work on the driver. Here is a .diff patch that will fix this issue: http://raidenii.net/files/igs011fix.diff
Here is another patch against 0.140u3 (so you’ll have to reverse the previous patch, if you used it, with -R) and our final update for 2010. If you wait a little bit longer, these changes should show up in MAME 0.141 along with other improvements. nimitz’s Shmupmame 3.0, based on MAME 99, should also have these changes. Here’s a list of changes for those who can’t really hear the difference:
The clicks caused by transitioning between samples was removed using a bit of what I consider a hack — an envelope, starting at 0×40 and decremented by one each sample cycle, that is multiplied against the normal volume. When it reaches zero, the channel is effectively off. Key on is instantaneous to avoid killing off the short, already soft sound effects.
The so called ‘approximate exponential’ formula for volume described in the patent is used and sounds much closer to the OSTs for the soundtracks. I think it may be ‘perfect’, but we won’t know for sure until the real hardware is tested. Also, as it turns out, Aaron Giles used the same formula in his ES5506 driver so we can be a bit more confident about its accuracy since the ICS2115/GF-1/ES5506 ‘OTTO’ are meant to be very similar.
Interpolation modified for looping, a temporary change. The entire accumulation logic will have to be rewritten as in the patent, which may help. This needs to be done for u-Law, 8-bit samples (not used in Cave games).
At this point I am reluctant to work on the driver until I have a decent hardware setup and a whole bunch of data. Any changes I make may make things worse, not better, because it’s already so close. Here is a video of Espgaluda in MAME with this current patch, I would say it’s almost there — with typical speaker setups it’ll be probably be indistinguishable from the PCB:
Anyway, I should get going, have a happy new year and we’ll see you in 2011.
UPDATE: MAME 0.141 is released, just before the new year in pacific time.
The ICS2115 audio chip was not perfectly emulated in MAME around the time the Cave PGM dumps were released, with good reason. There was a single datasheet flowing around which was extremely incomplete and even then it came along with some misleading information!
The first thing that really needed fixing was the tempo (i.e. timer control). The soundtracks were hilariously wrong. The initial fix was done by nimitz, trap15 and I, using a least squares fit and the OST as the reference. The results were good, but involved a bit of guess-work you see. As it turned out, we were close but it broke other games. Anyway, O. Galibert from the mamedev team then found the firmware for a soundcard that used the ICS2115 and was able to extract the actual formula, which was significantly more complex. Our method may have worked for the new games since they used a different timing “preset”, but it is time consuming and it is ALWAYS better to find out what is really happening instead of guessing, just to make sure you’re not off by any amount.
Anyway, as time went on, I couldn’t bear listening to the games — the flawed audio made them unplayable to me. The notes played too long, some notes were buried under the others, the volume was wrong, etc. etc. That’s when trap15 and I set about to rewrite the core. The first thing we did was try to find out if there were any chips similar enough to the ICS2115 to use as a reference. It turns out there was — the infamous Gravis Ultrasound (aka GUS), which used the GF1 wavetable synthesiser chip. Here’s what the chip looked like:
Yeah… it was the ICS11614 also made by ICS, as you may have guessed. It turned out it was extremely similar as revealed by the SDK Gravis released for it, downloadable here. Unfortunately, reading the SDK revealed that they didn’t understand the chip too well themselves as it was dreadfully incomplete. By this time, trap15 had rewritten the core from MAME and I was working in parallel to implement it using MAME’s new C++ interface. Eventually he had to work on other stuff and so did I to some degree, but I’m pretty obsessive about these things so I persisted, merging his changes along the way. Eventually, I encountered patent 5809466, which is a clone of the GUS amongst other things. This helped me write a more accurate core, but unfortunately there is still ICS2115-specific information missing.
Here’s a sloppy run through Daioujou BL’s first four stages, demonstrating the new core:
As you can see, it’s almost there. In fact, it will become more difficult to detect whether it is improving soon, so if you own a PCB/port of any PGM game and are familiar with what it sounds like, feel free to leave your comment. I don’t have the port on me as I’m away from my regular “home” so I don’t really have a reference other than the OST.
Any further results will come from reverse engineering the uploaded Z80 code to find out which conditions the remaining mystery commands are sent under (and what the return values for reads should be). If you have any information that could help us (like the missing ICS2115 SDK, mentioned on some ancient websites) please let us know!
A patch against MAME 140u3 can be found here. Apply it as you would normally apply MAME patches.
Oh … and before I forget, be sure to have a peaceful death. =p
I will post more about this soon, but first a tune!
Don’t mind the cropping, it’s an artifact from handbreak’s retarded aspect ratio correction interface. Oh and here’s what it sounded like before the new sound core was written, for your reference:
We have decided to completely scrap MAME’s old ICS2115 core, and write our own based upon the old core and our own findings. So far, we have achieved great success for the amount of time that has been put in.
As they say, a picture is worth a thousand words. If this is true, a video is worth over a million ;D Anyways, here’s a sample video of our new sound core, being used to play Knights of Valour 2 (Ketsui and DDP3, unfortunately, do not sound very good at this point in time, and I did not want to disgrace their soundtracks with this emulation).
We will continue working on this new sound core until it is as accurate as humanly possible. Thank you for your time.
So, after the experience of receiving countless glitch reports on emulation of Ketsui/DOJBL, investigating them and then discovering that there is in fact no glitch, we will require the following procedure before any time is spent on any claim:
1. Get an MD5 checksum of the MAME binary you are using and attach it to your report. If you are not using the mainline MAME binary (even if you compile it yourself) or shmupsmame, the report will be ignored. You may use this program if you are running windows: http://www.pc-tools.net/win32/md5sums/.
2. Now clear your nvram by deleting the [rom].nv file in the nvram directory. This might reset the settings to none defaults, but won’t be a problem in the future.
3. Record a short run reproducing the bug using the INP recording facility.
4. Find a reference which has the PCB displaying the correct behaviour and attach to your report.
5. Finally, make sure you’re very specific when describing what is happening. The more time you spend carefully describing the putative glitch, the faster we can investigate it and fix it if it’s actually a glitch. A vague report like “teh inputz lagth” will be ignored.
These guidelines will apply to any other driver we work on in the future. That’s all. Enjoy yourselves!