Raiden II Project Team
YOUR MISSIONS!

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

Enjoy!

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.

Since the release of MAME 140u2, we (nimitz, austere, and I), have been working non-stop to increase the accuracy of the Cave PGM for you.

Today we are proud to display our work, which has the following changes from main-line 140u2:

This work has been great fun for us, and we hope you enjoy the product of it as much as we enjoyed creating it.

As a side-product of change 2, I had to recreate the simulation in actual ARM code. This new code is called ASick72, and so far, recreates the Cave ROM perfectly enough to run all 3 Cave PGM games with no issues.

And now for some links:

• MAME Patches: http://www.raidenii.net/files/cavepgm.zip
• ASick72 (with binaries): https://github.com/SquidMan/asick72

Many thanks go to the testers at #iustek, #raidenii, #shmups, Shmups forum, and MAMEdev.

Please, send all donations not to here, but to Dr. Decap. He is far more important, providing constant, accurate and very important emulation resources. His website is at http://decap.mameworld.info/

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)