Daifukkat.su

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.