Strange that nobody noticed

Check the final level of Fairyland Story ending on MamEnd.
The background graphics are quite obviously broken in the top left corner! Strange that nobody reported this bug.

Anyway, I've fixed it now.

I've also been studying what the MCU does in that game, and the programmers made some interesting choices.

First of all, the MCU can return data stored in its internal ROM. This is done with short tables that are needed at the beginning of a level, and when you die. More interestingly, the text needed for the continue screen is stored there, and since you can't continue until level 8, it would take some time for a bootlegger to notice the problem. Even more interestingly, the endgame text is stored there, so one would have to play all the 101 levels to get to the protection.

Another wicked part of the MCU protection is that before action starts in a level, the game takes three bytes, performs complicated calculations on them to convert them into an 8-byte number passed to the MCU, and the MCU then performs more complicated calculations, recovers the original bytes and sends them back. A lot of work to essentially do nothing.

Finally, during the final level, the MCU is used to calculate and update the trajectory of the dragon's fireballs. Without the MCU, the dragon doesn't fire. I just have to wonder: why bother? How many people would have reached the final level in the arcades? And would bootleggers have bothered anyway? Figure some player going to the arcade owner and asking for her quarter back because the ending was too easy :)

Snowball effect

As you might already have seen on Haze's WIP, yesterday I succeeded in decrypting Gardia and Space Position.

This was an interesting case of pieces falling into place rapidly one after another.

The first piece was the decryption of Calorie Kun, thanks to a decrypted bootleg which was recently found. This didn't look like a particolarly interesting breakthrough at the moment: the encryption algorythm was already known, the key would have been difficult to find by hand but with the reference of the bootleg it could be derived automatically in a few minutes - just the time to write a program.

This renewed my interest in the remaining Sega encrypted games that use this algorithm, in particular Gardia. David Widel revealed that he had decrypted a portion of it months ago, but got stuck and put aside the results without publishing them. Believe it or not, he decrypted most of the code by comparing it with My Hero - even if that's a completely different game, it shares a lot of almost identical code with Gardia.

The data David provided was very useful to get started. Another really useful coincidence was that we have two sets of Gardia (one supposedly being a bootleg, but still encrypted). The two sets are different versions, with code shifted by a few bytes in places. This is an ideal situation when decrypting games that use simple algorithms like this one. When you have decrypted a portion of code in one set, you can use it to decrypt the same portion of code in the other set; but this way you also automatically decrypt some more code in the second set, which is still encrypted in the first set, so you can go back to the first set and decrypt even more code, and so on - you slowly build up the two keys in parallel.

While I was doing this, I rapidly noticed that the key used by the second set for opcodes was identical to the one used by the first set for data. Shortly afterwards, I also noticed that the key used by the second set for data was identical to the one used by the first set for opcodes - just shifted by one byte.

At that point I was on the lookout; I have to admit that I didn't notice it immediately, but eventually I discovered that the keys were actually the same as Calorie Kun, apart from the shift. When I found that, I just copied the whole Calorie Kun keys and I was almost finished - Gardia booted but had some problems. I just had to find a few more bytes at the end of the key to fix them.

Space Position was the easiest of all. At that point I was almost sure it would have used the same key. I checked some bytes of the partial key I had manually derived years ago, matched them with the known key, copied over the data with the appropriate shift, launched the game, and it was already working, on the first try - apart from the emulation issues which Haze later fixed.

This completes the decryption of all currently known Sega games using the "easy" Z80 encryptions. Unfortunately there are a few encrypted Z80 games left, using the suicide MC8123 CPU, which might be lost forever: all boards using the CPU seem to be dead, and the key is just about impossible to find without an hardware attack.

Easier than expected

Bryan noticed that changing a single value in the Pocket Gal Deluxe decryption (related to the address scrambling) revealed some clear text in Diet Go Go. THis means that the encryption key is almost hardcoded as I expected, but with some minor variation (maybe externally to the DE102 iself).

I have isolated the variations in just two numbers, a 16-bit one for the address scrambling and an 8-bit one (or two 4-bit ones) for the data bits permutation and xor.

Fine tuning the values to correctly decrypt data in Diet Go Go was easy enough.

Double Wings required a little more works, but it was still easy. I just needed to brute force the 16-bit parameter. Doing that was easy because I just had to decrypt the ROM using each possible value for the parameter, and count how many zeros were in the decrypted data. When their number rised from a couple of thousands to tens of thousand, I had a "good enough" value for the parameter, which I could later tweak by hand.

So, data was decrypted in all four games (the other one is Boogie Wings which decrypted with the same parameters as Pocket Gal Deluxe), but opcodes were still encrypted.

However, most of the work was already done. Even if the opcodes are encrypted differently from data, the address scrambling must of course be the same, otherwise there wouldn't be a 1:1 correlation between logical address and physical address. Therefore, only the data bits permutation and xor changes.
The obvious candidate for that variation was the 8-bit parameter. A brute force search was even easier in this case. I just had to try all possible values and count how many times 4E75 (the opcode for RTS) appeared. When it increased from a couple of times to several hundreds, I had the key.

So all four known games using this CPU (Pocket Gal Deluxe, Diet Go Go, Double Wings and Boogie Wings) should now be fully decrypted.
Non of them is working; for that, the driver will have to be finished, and possibly some more protection worked around. But the first hurdle has been overcome.

DE102

The recent discovery of a decrypted bootleg of Pocket Gal Deluxe was a pleasant surprise. This is one of a handful of games that use the same encrypted custom CPU - called DE102.
It is now confirmed that the CPU is a 68000.

Thanks to the bootleg, I was able to figure out the decryption algorithm. It is quite straightforward, and it involves:

• Address scrambling. When the CPU wants to read a word from logical address N, it fetches it from ROM space at address N'. The scrambling of the address requires 16 conditional XORs with 16-bit values.
• Data bits permutation. After reading the word from ROM, the order of its bits is altered. There are 16 possible permutations; which one to use depends trivially on the logical address.
• Data XOR. After changing the bit order, the value is XORed with one of 16 other values. Which one to use depends trivially on the logical address.

While working on Pcket Gal Deluxe, I was hoping that the DE102 would use a fixed key, which would have emant free decryption of a few other games. Unfortunately, this turned out to not be the case. The algorithm surely is the same, but the key is different.

Determining the key without having a decrypted version to compare with is a lot more difficult, as you can imagine. Also, it seems that at least one of the other games encrypts data and opcodes differently, which makes things a lot more complicated.

In the next days, I'll see if I can find a way to break the key somehow.

Great Swordsman colors

Sprite colors in Great Swordsman have been one of the longest standing and most elusive emulation imperfections to date.
It was hardly noticeable, because a manually crafted lookup table had been crafted in the driver, so colors looked ok.

Finally, thanks to Kold666's invaluable help, the emulation is now perfect.
As you can see in the shots, the difference is subtle but it's there. It is probably most evident on the pulsing logo, whose color changes are now slightly smoother.





The way how I achieved this is worth of mention. Kold kindly provided some pictures of the pcb (parts side and solder side). I x-flipped the solder side, overlapped them in a gfx editing program, and carefully aligned them so I could see both layers at once. Then started tracing from the color lookup PROM, to see what the board does with the data.

In the end, it turned out that the sprite palette data comes from a row of the character palette, the tricky part being that the order of the 4 bits coming out from the lookup PROM is reversed. This is something that could have been noticed before, but it always eluded me.

Panic Road

I didn't have much time for MAME in the past few weeks, but tonight I could finally do something again.

This time I decrypted the graphics for Panic Road. The encryption is just a simple data and address lines swap, so it wasn't particularly hard to do - but it took some time nevertheless.

I don't have time to finish the driver, this will be a job for someone else.

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.

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.

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 :)

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.

Polyphony

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

Cacophony

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.

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 :)

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.

Child's Play

Well not exactly, but with the knowledge gained working on the other games decrypting Raiden Fighters Jet wasn't too hard.

Done

Finished decrypting the sprites in Senkyu, E-Jan High Scool, Raiden Fighters and Viper Phase 1.

Raiden Fighters Jet is the only one left. It uses a different encryption, which might be similar to the one used by Raiden Fighters 2 2000.

Almost Done

Things are beginning to look pretty good.
I still have many things to fix, especially for sprites with (tileno&0x4000) , but most of the work is done now.

Getting There

I made a breakthrough yesterday night and could fill most of the gaps.

There is still a lot to do. Part of it is simple and just requires trying various combinations until the correct one is found; I should be able to do it the next night I dedicate to the encryption. The rest is less simple and requires finding the remaining (and therefore less obvious) correlations between bits. However, the closer I get to the goal, the easier it is to see if a certain formula is correct or not.

Sprites are finally good enough to show a screen shot.

13 1/2 done, 34 1/2 to go

That's a strange way to report progress but it's the number of bits in SPI sprites that should be correctly decrypted at the moment. The encryption works on 48 bits at a time, and I have to decrypt each one of them.

Luckily, having decrypted Raiden Fighters 2 makes things easier because the first few sprites in Raiden Fighters are identical, so I can compare them and see where pixels should go. However, the process isn't easy because the SPI sprite encryption is quite more complex than the tile encryption. Of the 34 1/2 bits still left to do, 16 will be particularly hard because the encryption scrambles them more aggressively. The others shouldn't be too hard to do, given enough time and patience. I have plenty of the latter, but never enough of the former.

First results

Decrypting the sprites was easier than expected. I've done Raiden Fighters 2 for now, which is the first game to have completely decrypted graphics. I still have to do Raiden Figthters Jet and the SPI - I don't yet know if the encryption will be similar.



The game looks good now, though there are still some graphics issues - most notably priority and alpha blending. I will probably not look at those when I've finished with the decryption, leaving to someone else to finish the driver.

And now comes the hard part

Fixing the tile banking was easy, so now I can't postpone any longer the attack to the sprite encryption.
That should be significantly harder to fix than the tile encryption, I haven't even looked at the current algorithm yet so I haven't devised a strategy.

All RISE!

On one side, decrypting the tiles of the RISE11 chip used by Raiden Fighters Jet was easier than I thought: after placing a few bits of the source data, it became apparent that the bit order was the same as the RISE10 chip used by Raiden Fighters 2.

On the other side, however, it wasn't that easy because a couple of pixel didn't want to decrypt correctly. Eventually, it turned out to be a carry that wraps around from bit 23 to bit 0. Nasty!



So I have finished decrypting the tile graphics in all Seibu games. What I will have to do next is fix how the tiles are rendered on the screen in the RISE games, because currently the tilemap layers show garbage most of the time. The above shot is pretty much the only place without graphics errors (caused either by tile banking, or sprite encryption).

Autopilot

It's true that sometimes when you are blocked on a problem you just have to leave it aside for a while to look at it from a new perspective.

Yesterday I spent much of the night fixing the tile decryption for the RISE10 chip, which is used by Raiden Fighters 2. With the experience gained on the earlier version of the chip this was much easier, and I could fix most of the problems reasonably quickly. However, there was one bit in one layer that just didn't want to work.

The algorithm, now that it's understood, is really clean and simple, following intuitive patterns, but that bit didn't fit - to partially decrypt it, I had to use the wrong bits from the tile code, and pick a carry from the wrong bit of the encrypted data. It just didn't make sense.

I decided to leave it alone for the night, but literally a few seconds after turning off the monitor and going to bed, the obvious answer came to me: that bit had to belong to a different plane! I must have been fetching the encrypted data from the wrong place. And indeed, this morning I checked, and bit 16 of the source data was used twice, while bit 15 was not used at all. Fixing that was all that was needed to completely fix the tile graphics.



There aren't many screenshots that I can take because the driver also has problems selecting the tile bank (this is an emulation problem not related to the encryption). Plus of course, sprites are still not decrypted correctly.

I still have to decide what to do next - I could either look at the RISE11 encryption, used by Raiden Fighters Jet, which will be a bit more work than the others because the current driver only decrypts two of the six planes (for the other games, the decryption was already very close). However, now that I have a good understanding of the algorithm it shouldn't take long to do it, even starting from scratch.

The other thing I could do is fix the tile banking problems in Raiden Fighters 2. I haven't looked at the driver yet, it might be something simple.

SPI progress

I started from the part that was in the best shape, the first version of the tilemap layers, and fixed the decryption errors.



This encryption is used by Senkyu, E-Jan High School, Viper Phase 1 and Raiden Fighters. I will look at the other versions of the tile encryption next. Sprites are harder to do and will be done last.

Seibu SPI encryption

I'm looking at the Seibu SPI graphics encryption at the moment. For now, I'm fixing the small mistakes in the tilemap layers of Senkyu etc., after that I might look at the sprites as well.

Most of the work has already been done on the tilemap layer, but there are some mistakes. I have understood while they are happening and already fixed one of them. It's clear how the algorithm works, it's a bitswap + arithmetic calculations (additions instead of simple XORs - this is not common). Replacing the lookup table with formulas and fixing the remaining bugs is just a matter of time and patience at this point.

F3 sound

The issues with F3 sound were intriguing.
These games all use essentially the same sound program, with minor variations, which appears to be a generic MIDI player.

The hardware is capable of driving a large amount of ROM data - more than the ES5505 is capable of, so the ROMs are banked, in 4 or 8 banks depending on the player version. The ROMs are actually half the amount of banks, because every ROM contains two banks (apart a couple of exception games that use smaller ROMs).

At the beginning of each bank, the ROMs contain a standard header that the program reads on startup to see what samples are available. Therefore, the order how the ROMs are loaded isn't strict - if you swap two of them, the program will still know which one is which and play the correct samples anyway.

However, there's a catch. Most of the games have one ROM containing standard samples (the same in all the games that have them) and those samples are stored differently from the others (there is no header), so the program cannot recognize them. The program just expects those standard samples to always be stored in the last bank.

Discovering this was important to fix sound in a few games - for examples Space Invaders DX, which was missing music.

However, it still wasn't enough to fix all the problems. For some reason, ROMs loaded in bank #4 were not recognized properly, so they were ignored by the program. After some studying of the ROM detection function, I finally found the not-so-obvious cause.

Usually, 68000 programs have ROM starting from address 000000, because that's where the reset vector is located. This program, however, for some reason works differently, and ROM is located higher in memory while RAM is at 000000.
The 68000 also has a special instruction to move data in its address registers, called MOVEA. It is different from MOVE because a MOVE.W will just affect the bottom 16 bits of the destination register, while MOVEA.W will sign extend the result to 32 bits. Therefore,
MOVEA.W #$7FFF,A0
will put #$00007FFF in A0, while
MoveA.W #$8000,A0
will put #$FFFF8000 in A0.

What was happening with the program was that the data read from the ROMs went to a buffer starting at around #$006000, and continuing onwards until it crossed the magic #$008000 boundary. When it did, the program would begin writing data at #$FF8000, but read it back from #$008000. This is what is called a "mirror address" - different addresses that map to the same chip on the board. The FF8000-FFFFFF area was mapped in the driver, but not as a mirror of 000000-00FFFF. Once that was fixed, the program started properly recognizing all of its ROMs.

I have checked all the games, looking at the ROMs to make sure they were in the order expected by the game, and playing them to look for obvious problems, and I couldn't find any, so now all of the F3 games should be sounding pretty good.

In the process, I also discovered that Quiz Theater was missing sound because of a bad ROM. I was able to partially repair it because most of the damage was in a portion which is common to other games, however there are still some parts missing so some sounds willnot play as they should. Ring Rage and Riding Fight still have no sound, however in this case I believe it's an emulation issue. Both of these games use a very old version of the sound program, possibly the earliest revision, so it might behave a little differently from the later ones.

Universal, part 2

But the strangest thing about Mr Do's Castle board is the third Z80. This CPU has a tiny program ROM - 256 bytes, and most of them empty. It sits there, doing almost nothing. It communicates with the main CPU using the same method described in the previous article, but it doesn't send anything back.
The interesting thing is what the main CPU sends it. It's not just 9 bytes as with the second CPU. It is 0x200 bytes, and it's the sprite data. So essentially what the third CPU does is sit there, wait for the sprite data from the main CPU, and pass it over to the video hardware.
Why couldn't the main CPU just send the data to the video hardware by itself? That's the difficult question. I haven't an answer yet.

Universal

Universal, best known for their Mr. Do! series, surely made original games. Their hardware isn't less original; it's actually one of the more unique and strangest ones in MAME. A lot of things in their boards were done differently from everyone else, and in non-obvious ways.
Even the style of the schematics drawings is unique and instantly recognizable - albeit not the easist to follow.

There is a long standing problem with the games Mr. Do's Castle and Do! Run Run, where the dip switch settings are not read by the game. The problem has been reported to happen even on real boards, so it is probably a timing issue (small deviations from the nominal rates of the components could throw the timing off enough to break it). For now, we'll fix it in MAME by just changing the CPU clock rate by a small amount. Kind of black magic, but it works.

Anyway, while studying the schematics I finally understood one thing that had eluded me until now: how the CPU communication happens on the real board. The two CPUs exchange bursts of 9 bytes, but there is only a single bidirectional buffer between them. How could it possibly work? Well, the Universal designers took advantage of the Z80 WAIT input. When the main CPU reads or writes the buffer, the WAIT line is asserted, so the CPU is put on hold. When the sub CPU reads of writes the buffer, the WAIT line of the main CPU is cleared, thus making it resume execution. So when the main CPU writes to the buffer, it will put the data there and pause until the sub CPU has read it. When it reads the buffer, it will pause until the sub CPU has written data to it, and resume execution (reading that new data).

Very cheap and effective. However, I wouldn't want to fly on a plane that uses this technique. :)

I wish they were all like this...

I was asked to look at the encryption of a game called Super Trio, and it tunerd out to be some very basic XOR on the bottom address lines, surely done by a PAL near the 68000.
One wonders why did they even bother to encrypt it, if it was so trivial to break (moreover, surely a PAL based encryption would have posed no problem for any bootlegger).

Anyway, I don't have time to write new drivers these days, so my job is done. Hopefully the hardware won't be difficult to figure out, so we'll soon be able to revive another nice and rare game (as I'm told).

Chain reaction

It seems that whenever I look at a driver, I find something to fix in it
In this case, while looking at TNZS, I noticed that some games, e.g. Insector X and Plump Pop, were quite obviously running at 30 fps instead of the normal 60. This makes a lot of difference in the smoothness, strange that nobody ever noticed. Anyway, this was caused by missing support for sprite banking, a feature of the hardware which was already supported by seta.c (the games running in this driver use Seta custom chips). It's now fixed so Insector X looks better than ever :) The improved emulation also fixed the various gfx issues with Kabuki Z.

Some bugs never die

Fascinating how some bugs have stayed with us for years, even if the solution was simple and obvious.

There had been two bugs plaguing emulation of The New Zealand Story:

1. A hanging bug, which would make the game simply stop, while music was still playing. This happened randomly at some key points, typically the end of a level when you touched the cage. This was caused by a bug in the original program (a RET NZ instead of RET Z), which would cause no apparent problem on the real hardware, but could be deadly in MAME.
   This bug had been fixed for a long time, 0.91 contains a cleaner workaround but the behaviour is the same.
2. A crashing bug, happening at different times in the three different versions of the game. For example, in the current main set, it would happen when the cannon-firing sheep was on the screen. This was caused by a known limitation in the MAME handling of banked ROM areas. It is not a big problem, and we know how to deal with it, and there was code in the driver to do that. Unfortunately, the code was copying the wrong data! It has been like this forever, and nobody ever noticed. But at last it has been discovered, so I can promise you, from 0.91u2 TNZS will no longer crash :)

Kram is working!

I have finished the manual decryption. By that I mean that I made tables that list all addresses of encrypted instructions, and what to replace them with. The total number of entries in the tables is 7926. This is not an optimal solution but since I doubt I will manage to understand the algorithm it's the only thing I can do.

An interested thing I found out when hooking up the tables in the driver is that for two-byte opcodes, only the first byte is encrypted, the second is unencrypted. This wasn't the case with the Konami-1 CPU, where both bytes are encrypted. Odd.

Reaching a brick wall

No progress on the Kram encryption algorithm. Changing even a single bit of the address changes the result in an unpredictable way. At this point I'm doubting that I'll be able to derive the algorithm.

Manual decryption of the game, instead, is proceeding. I'm at about 80%, I think. The service menus are working, while the game is still booting to a black screen.

Kram hurdles

Looking for "good" keys didn't work, there are no bit permutations that show noticeably better applicability than others, the only thing I found is that a 0x22 final xor is significantly more common, which is good on one side, but not that good on the other side because it cannot be the ONLY xor - there must be others.

The manual decryption by comparison with the other sets is almost complete, CPU #2 is 100% while CPU #1 is maybe 75%. The code is different in a few places because this version doesn't have the MCU, and actually there seems to be a large chunk of code in the encrypted version that isn't in the others, so I might not be able to do a complete decryption if I don't break the encryption algorithm.

One interesting thing to note is that the code has been reassembled with a different assembler, which generates different (but equivalent) instructions in some cases. Here is an example:

not encrypted version:

D08D: CE B8 D3      LDU   #$B8D3
D090: EC 84         LDD   ,X
D092: 81 29         CMPA  #$29

encrypted version:

D082: CE B8 D3      LDU   #$B8D3
D085: EC 00         LDD $0000,X
D087: 81 29         CMPA #$29

the middle instruction does the same thing but with a different opcode.

Yesterday I verified that bytes at the same address are decrypted in the same way, and that in that case changing one bit in the encrypted value changes one bit in the decrypted value. Tomorrow I will try pairs of addresses only differing by one bit, and see if there is a similar regularity. From what I could see, however, I'm not very optimistic.

Kram progress

My intuition was right: the two Kram CPUs use the same encryption. Every time there is the same encrypted value at the same address in the two CPUs, it decrypts to the same value.

Not only that but, at a given address, if N bits change in the encrypted value, then N bits change in the decrypted value. This proves that the encryption consists of a bitswap and a xor.


That was the good news. The bad news is that the encryption changes with the address, and there isn't much data to analyze. For most addresses I have only one encrypted-decrypted pair, for a few I have two. There is no way to obtain more than what I have without physical access to the CPU.


Of course, since for now we have to assume that the encryption consists of a free bitswap + free xor, this means that given a single pair it could be decrypted correctly with any of 8! = 8*7*6*5*4*3*2*1 = 40320 different keys: just pick any of the 8! possible permutations of the bits, and then select the 8-bit xor that fixes the result.


What I need to do now is try to figure out the relation between address and key, which isn't obvious at the moment. The total possible keys are 8! * 2^8 = 10321920, which isn't too much. What I plan to do is check how many values are decrypted correctly by each one of them (or better, by a subset of them). If we are lucky, some keys will show a significantly better success rate, meaning they are "good" ones. If we are not lucky, it will mean that bitswap and xor are independently affected by the address.

Kram encryption

And of course, another still unsolved issue with the Qix driver is the encrypted version of Kram.


This is unusual because it's possibly the only time that Taito used encryption instead of MCU protection (off the top of my head, I can't think of any other encrypted Taito game). It is also a rare example of an encrypted 6809 game - again, the only other 6809 encrypted games that come to mind are the ones using the Konami-1 CPU.


I had looked at this encryption other times in the past, with no success. There probably isn't enough data to figure it out, but comparison with the other version of Kram will at least be enough to decrypt it, even if it will mean using a large hardcoded table - and who knows, in the process I might discover something new.


The encryption only works on opcodes, leaving data decrypted, which is good because you can easily align code from the encrypted and unencrypted versions of the game. Unlike the 68000, where everything that is fetched in the process of executing an instruction (plus PC-relative indirect memory accesess) is considered program space, and only memory accesses caused by an instuuction are considered data space, in the 6809 only the first byte of an instruction (the opcode itself) is encrypted, while the other bytes of a multibyte instruction are left unencrypted. This means that when comparing encrypted and decrypted blocks of code you have plenty of reference to align them perfectly.


The encrypted version of Kram should actually be almost identical to the other two, minus the MCU handling which isn't present in that version since it was protected in another way (Sega, anyone?). I should be able to do most of the decryption automatically and fill a couple of holes manually in the places that are different. Since both 6809 are encrypted, my hope is that they use the same encryption, so I might discover something more about it by comparing encrypted bytes at the same address on the two CPUs.

Fix one thing, discover another

Electric Yo-Yo was easy to fix, it was crashing because of a synchronization issue between the two CPUs - increasing interleaving fixed the problem.


Looking at the schematics surely was interesting, for example I discovered that the video ROM bank latch (which is a late addition only present in Zookeeper) is mapped on a mirror address of the diagnostic LED / palette bank latch. This explains why they oddly mapped the ROM banking bit on data bit 2, instead of the more obvious bit 0. That's because bits 0 and 1 are the ones that control the palette bank, and since the ROM bank latch is at a mirror address of the palette bank latch, whenver the former is written to, the latter is affected as well. So whenever the game wants to set the ROM bank, it also copies the palette bank in bits 0 and 1 to avoid unwanted side effects.

Memories...

I'm looking at the good old Qix driver at the moment. This was one of the first drivers in MAME, and at the time it seemed really complex, with its three CPUs and the need to synchronize them with a certain degree of accuracy.

The driver is already very well written and documented, but I'm checking the schematics again to verify that everything is correct, then I'll try to fix the Electric Yo-Yo hang during attract mode.