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.

And of course, here is the new src/mame/video/nmk16.c : http://raidenii.net/files/nmk16.c

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:

By the end of this, I should have 100% at the least for these games!

Enjoy!

• 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 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

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:

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.

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!

We’re still working hard to provide you with the best possible emulation experience, so keep watching!

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/