Tue Sep 9 22:52:23 EDT 2014

NMK004 ROM Dumping, Part 3: The Previous


Title screen of Thunder Dragon

This is post is a sequel to a previous post. I highly recommend reading it before this article, or this one may not make much sense: http://daifukkat.su/blog/archives/2014/09/07/nmk004_rom_dumping_part_2/

In the time since the last post I have finished dumping, reconstructing, and verifying the NMK004 internal ROM. With the help of David "Haze" Haywood, it has been hooked up to MAME. As a result, all of the previously listed games now have perfectly working sound. With the sprite priority fixes I submitted a while ago, I think this pushes the emulation quality of almost all games on NMK's hardware up to "acceptably accurate" at the very least. Expect to see these changes come to MAME within a week or two.

In August 2013, I had submitted fixes to the sprite priority emulation on NMK hardware. Later in the month, I decided to probe the Emuversal shoutbox for opinions on my work. While on the subject, I also mentioned the NMK sound's poor state, and that I hoped it would be fixed soon. Haze replied, and told me that the NMK004 internal ROM was probably only extractable with a decap. There was also a mention that someone speculated that it would be possible to extract the internal ROM by playing it out as sound data, but that the setup would be complex and that nobody had tried to do it yet.

After a bit, I asked for and was given some TLCS-90 datasheets (the same CPU used in the NMK004) as it was assumed that's what it was. Unfortunately, the NMK004 ended up not being the same MCU model as were in any of those datasheets, but I eventually found the correct one much later. The actual model seems to be a TMP90C840, datasheet available at: http://raidenii.net/files/datasheets/cpu/tmp90c840.pdf


Title screen of Vandyke

The next day, I spent some more time probing things and poking people on the Emuversal shoutbox, trying to get a feel for the possibilities for dumping. I concluded that I should try to play out the internal ROM with one of the tables, record the outputs, then analyze the sound files to recover the internal ROM. Within a few hours I had cooked up a sample ROM that attempted to play things out from the internal ROM. I did a short test in MAME just to verify that it would make sound, and it did. From there I made a reference ROM that I could use to compare the various values. By this time I had decided on using PSG note length as my dumping table, due to its long spread and easy reconstruction method.

I had tried to ask people to make a reconstruction tool for me, but this never materialized. I figured it'd be trivial enough, so I wrote my own (extremely ghetto) tool that could analyze the resulting WAV files from recordings. My recording setup involved using an RCA->3.5mm adapter to connect the sound output of my supergun to my PC's microphone port. From there I would open Audacity and let that record until it stopped. When it would stop, I would save the output as a WAV file, perform the conversion, then compress the WAV file down to a good quality OGG and throw away the WAV file. Writing the tool for analysis took a good couple hours, though the tool ended up being pretty solid and worked very well.

After the tool was written, I started dumping the first 256-byte block of the internal ROM. This block was one of the quicker ones to dump, and took five and a half hours for just the first 256 bytes. The next day, I decoded the dump, and got my first validation that everything I was doing was correct and working: "All Music,Effect Software(C)1990 N M K Corporation". You wouldn't believe how excited I was when I saw this message, one that is likely to have never been seen by a single person in literally 20 years, in the converted dump. Unfortunately, the rest of the dump was far from as exciting. Waiting 8 hours for each 256 bytes to dump is absolutely not the best way to keep motivation high, especially when the ROM to dump is 16384 bytes long. Each block takes so long to dump because of the way I'm doing the dumping. Since I was using note lengths, a small 16-bit value would dump extremely quickly, and a high one would dump extremely slowly. For reference, a $FFFF value takes about 7 minutes to dump. Multiply that by 128, and a 256-byte block of $FFFF takes 15 hours to dump. Luckily nothing was that absurd in the blocks that I had dumped.

Eventually I gave in to the length. Sadly, looking back on it, I noticed I was very close to the end of actual data. My last set was $1200-$12FF, and the actual contents of the ROM end at approximately $1400. Everything from $1400 to $1FFF is just an $FF fill, which would have taken ages to dump if I had bothered to do so. It's been about a year since that last excursion, and I'm very glad that I went back and finally got it done. The previous attempt was a serious headache, and I knew that if I made the procedure less of a total headache, I could get it done.

I realize this hasn't been that technical of a write-up, but the lack of notes makes it not too easy for me to write about the technical side and what didn't work. What it essentially came down to, technically, was setting the Shared note length table's pointer to point into the area to dump, then having a bogus song that would play out a note of each length. I seem to recall I also used a padding note between each actual dump note, to help segment them up and make the conversion tool simpler, but I couldn't say for sure anymore.

The next post will be around in a few days, detailing the final attempt all the way down to the nitty gritty. I'm still undecided how I want to release the ROM, but I think I'll figure it out before publishing the next post.


Posted by trap15 | Permanent link | Comments (9) | File under: arcade, nmk004, mame, emulation, reverse_engineering
Iq_132
comment #0
2014-09-10 11:30:34 EDT
That is an absolutely ingenious solution. Is it safe to assume that every nmk004 internal rom is the same or was some hacking required?
trap15
comment #1
2014-09-10 19:49:22 EDT
Yeah, it's pretty safe to assume that, especially since all the games work with the one I dumped from my Thunder Dragon. I'm going to release my dumping tools and a whole bunch of documentation when I release the ROM, so others can duplicate and verify my work if so inclined.
Extra
comment #2
2014-09-10 20:21:54 EDT
With the sprite priority fixes I submitted a while ago, I think this pushes the emulation quality of almost all games on NMK's hardware up to "acceptably accurate"


Isn't Rapid Hero affected by this (it's not in your list)? Which are the NMK16 games still with non-accurate graphic emulation on MAME, as far as you know?

Thanks and congrats.
jark
comment #3
2014-09-10 20:58:57 EDT
Nice work,trap15,does nmk004 rom help those nmk games what have GAME_IMPERFECT_GRAPHICS flag?
trap15
comment #4
2014-09-10 22:18:12 EDT
A lot of games that I didn't list earlier were affected by those sprite priority fixes; almost every game in the nmk16.c driver was fixed, even. I think at this point it's safe to remove GAME_IMPERFECT_GRAPHICS, but I didn't want to remove it until I'd verified against PCB recordings. By now I've seen and compared them enough to be sure that it's ok, so that flag will be removed when I submit the NMK004 patches.

The NMK004 ROM does nothing for graphics, only sound. It should fix all the GAME_IMPERFECT_SOUND flags in the driver, I think.
Extra
comment #5
2014-09-11 06:02:22 EDT
Yeah, sorry, I didn't mean to word it like that. My first question was if Rapid Hero has now accurate sound emulation, given that it's not in your list. It's now addressed, I guess.

As for your other answer, I take then that this:

http://mametesters.org/view.php?id=1117

can be closed now?

(And also this one:

http://mametesters.org/view.php?id=3395

my guess?

Thanks again.
Extra
comment #6
2014-09-11 07:01:06 EDT
Ah, wait. They didn't use the NMK004 on Rapid Hero for some reason. Always thought otherwise.
trap15
comment #7
2014-09-11 20:40:55 EDT
Rapid Hero's sound was fixed around the same time as the video fixes went in. The issue was just that the sample ROM banking was handled totally wrong.

The previous fixes and the ones coming in will be fixing a lot of mametesters bugs, I intend to gather a list of the fixed ones and post that along with the ROM and such.
Extra
comment #8
2014-09-12 09:05:48 EDT
So nice. If you're taking votes for the next everly-forgotten-by-the-author MAME driver we'd love you to check and perfect once and for all, please, let us know here!