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