Tuesday, March 22, 2005

How to dump a NMK004

This is still at the theorical level, until one of the hardware gurus gets his hands dirty and tries to put it in practice.

The NMK004 cannot be dumped directly using the common methods, but the way it operates can probably be used to extract the internal ROM data in another way.

The external ROM contains data tables used to play the samples and music; but not only that, it contains pointers to those tables.
By changing those pointers, we can make the NMK004 use its internal ROM as if it was one of the external tables. In particular, this can be done with the table that contains the sample numbers to be played by the two OKI6295.

We can then log the commands sent by the NMK004 to the OKI6295, and this will allow us to determine which sample it is attempting to play - and therefore the value of the internal ROM byte it has just read.

So in theory there shouldn't be problems - unfortunately the hardware setup needed to get it all to work isn't trivial. But I'm confident that in due time it will be done.

Thursday, March 17, 2005

NMK004 update

As most of you have already seen, a few days ago Haze released an update with the first version of my NMK004 simulation code.

All NMK004 games have sound, though in some of them it's better than in others. Mustang is possibly the worst one - I have doubts about the sound ROM being a bad dump.

There were a few major problems - music stopping shortly after starting, or games completely freezing MAME. I have found a bug in the loops handling which should have caused most of these problems. Here is the fix. It doesn't improve Mustang, though.

Sunday, March 13, 2005

Digital Fortress

Which is the book I'm reading now.

I really don't have much time to read, as you can imagine working on MAME eats up most of my spare time. However I try to read something even if it means just a couple of pages per day.

I had read the bestseller The Da Vinci Code previously, and didn't feel any urge to read another book from the same author, especially after I noticed that all bookstores are now prominently displaying his previous works, which had went entirely unnoticed until the success of The Da Vinci Code.

Digital Fortress in particular was written in 1998. The publisher must have been unable to find any positive review to reprint on the back cover, because they resorted to quoting "Praise for The Da Vinci Code". However I was intrigued bu the theme of the book, which is cryptography - and I was able to borrow it from a friend, so I gave it a try :)

The problem with fiction is that you must be able to suspend disbelief to immerse in the story. This isn't easy if what is being thrown at you makes no sense at all. This was also a problem with The Da Vinci Code, of course, but not knowing much about art history it was easier to fool me. Mathematics is supposed to be my field, so fooling me gets a little bit harder.

Right at the beginning of the book, on page 29, the author introduces Julius Caesar as "the first code-writer in history", and talks about a "'perfect square' cipher box" he supposedly use. This is a transposition cipher, which consists of arranging the cleartext in a square and reading it by columns to get the ciphertext.

Well, I had never heard of this "Caesar's box" cipher. The encryption commonly associated with Caesar is the one called "Caesar's cipher", and it is a substitution cipher: replace every letter with the one k places after it in the alphabet, so e.g. A becomes D, B becomes E, and so on.
A transposition cipher similar to the one mentioned by Dan Brown was used in Sparta, a few centuries before Caesar's birth.

OK, never mind. After all, I might just be ignorant not knowing about the Caesar's Box. Unfortunately, on page 34 Dan Brown talks about public-key encryption, and what he says makes little sense.

The comment that modern codes are "computer-generated has functions that employed chaos theory and multiple symbolic alphabets" was also funny - it reminded me of this :)

Monday, March 07, 2005

Almost good enough

I am at a point that I almost consider good enough. The FM part is supported as well. The state machine seems to produce the correct notes, the only strange thing is that the volume is extremely low - I had to push it to 2.0 gain and lower all the others to make it reasonable. There might be a bug somewhere in the way the FM parameters are set - this stuff is much more complex than the PSG.

At this point, I'm more worried about the protection in some games than by the sound, which is coming along nicely.

It has to be said that this simulation I've written was mostly for personal education and for reference. I am 99% certain the the NMK004 internal ROM can be extracted, using a technique I thought of. Theoretically it's very simple, but the process will require some hardware work.

And of course, once the ROM is extracted, we'll have to see if it can be ran in MAME. It supposedly is a TLCS-90, which is one of the few CPUs not yet supported by MAME, so an emulator for that CPU would have to be written. Which would be a good thing because it would also allow to support Mahjong If and sound in Rapid Hero.
Having the simulation code available might help while writing the CPU emulator.

Sunday, March 06, 2005


The problems with the PSG notes were just caused by a silly omission of a *2 in a table lookup. Things that happen when hacking around at 4AM ;)

The PSG part sounds quite good now. Only the FM part is missing...


Things are going rather well with the NMK004 simulation.

The NMK004 state machine supports:

  1. Six FM channels; each pair of them shares one of the three YM2203 voices.
  2. Three PSG channels, each one using one of the PSG voices of the YM2203.
  3. Eight Effects channels, which can use the total eight voices provided by the two Oki M6295 to play sample-based sounds like drums (but they are also sometimes used to play effects not music related).
  4. Direct triggering of Oki M6295 samples (this is not strictly part of the state machine)

Current simulation status is as follows:

  1. Not done yet.
  2. Partially done. The state machine works and seems to play notes at the correct speed. However, the pitch of the notes is way off.
  3. Seems to be ok.
  4. Is mostly ok but there are some strange things here and there - difficult to say if it's a simulation error or just how it's supposed to be.

I am growing more and more convinced that the internal ROM of the NMK004 is the same in all games. A few of the games in the driver have additional protection issues, but at this point I don't think they are related to the NMK004.

Friday, March 04, 2005

Sounds Promising

It looks like the Z80 sound program for Task Force Harrier, which is the only known game predating the introductionof the NMK004, uses a data format which is very similar to the one used by the NMK004.

The main command table and the sample tables are slightly different, and the music tables look very similar if not identical.

It would probably be possible to modify the Z80 program to use the different tables, but I think I'll take the longer route and rewrite the program in C - so I'll learn how a program like that works in detail, which can always be useful knowledge :)

Thursday, March 03, 2005

NMK Sound

One of the longest standing hurdles in MAME emulation is the sound in NMK/UPL games like Mustang, Vandyke, GunNail, etc.

Those games use an custom CPU, labelled "NMK004", to drive the sound. It is still not known what kind of CPU it is, what's known is that it has 8 or 16kB of internal ROM which cannot be directly dumped, and which contains the whole program. The external ROM only contains data.

I am convinced that that the program contained inside the NMK004 is either always the same, or it has minor difference to handle protection - but the format of the data in the external ROM is always the same.

What I'm trying to do at the moment is understand the format of the external data. I have started with the easy part, that is the Oki 6295 samples control. I have found the command table, and the mappingd from command to 6295 sample number. This allowed me to make the games play the correct samples at the correct time so e.g. in Vandyke I hear a "swoosh" when I swing the sword and a "uumph" when I jump. I still haven't understood all of the control bits, so it isn't perfect yet, but it's a good start for a night's work.

I'm hoping that other games that use a standard Z80 instead of the NMK004 will use similar logic to drive the sound (though I have already verified that they don't use the same data format as the NMK004).

Of course the YM2203 part will be much harder since it won't be just a matter of playinga few samples here and there, but I will have to fully understand how the data translates into music and drive the YM2203 accordingly. However there's nothing stopping it in principle, so I am confident that eventually I or someone else will be able to add full sound to these games.