CPS3 Emulation progress.

Skipping Ahead

Dox decided to hack around a bit with the driver, and found a way to skip some of the tests. As a result JoJo and JoJoba actually now execute some of the game code, rather than just the bios. They both hang after the Japan warning however. The code appears to be stuck in a big loop, dong not much at all.
Doing this properly is something of a pain in the backside due to the way MAME works. The games execute code from FlashROMs, however due to the way FlashROMs are accessed MAME must map them as Read/Write handlers in the driver, not blocks of RAM/ROM. MAME’s CPU cores don’t handle executing code from Read/Write handlers well, nevermind *encrypted* code (with the possibility of *decrypted* data) from such handlers. This is probably going to require some rather ugly hacking around.
Its interesting to note that JoJoba is the NCD set, while JoJobaa appears to be a standard set. They both however still check for the CD, so I’m guessing there must be something else to it too.
It’s also interesting to note that the dates these things are booting up with seem completely wrong. Maybe it’s not running the correct boot code.

Click to expand...

no. background / sprites will be hard, could take a few months.
Posted by: Haze at June 17, 2007 4:08 pm

Click to expand...

http://www.speksnk.org/foro/viewtopic.php?t=66324
ElSemi has some shots of the backgrounds up, I’m still debugging the code a bit in MAME, but the theory is all there. As you can see, ElSemi still has some bugs too.
Posted by: Haze at June 17, 2007 9:10 pm

Click to expand...

CPS3 Tile / Sprite Data Compression

CPS3 uses compressed data for it’s BG tiles and Sprite Data. The system has a ‘DMA’ list in Video RAM, and when given the command the video hardware will process this list, and copy + decompress graphic data from the FlashROMs into Video RAM for use by the game.
The compression initially looked rather complex, but actually turns out to be much more simple than first thought (although emulation still isn’t perfect)
The basics of it are simple. The first command in the DMA list is a special command, telling the chip to upload a 256 byte table to its internal memory. The Compressed data contains 8 bit values from 00 - FF. Byte with 0×80 set (0×80 - 0xFF) are treated as a lookup into the table it uploaded, replacing one byte, with one word from the table. This allows them to compress the 128 most common words to a single byte instead of a word, thus saving 50%.
After that there is an RLE stage, bytes with 0×40 set are command bytes, telling the chip to repeat the next byte a certain number of tiles. What you’re left with is a series of values between 0×00 and 0×3f, giving 6bpp (64 colour) sprite / bg tiles.
What isn’t quite understood is what happens if there is an RLE command byte followed by an RLE command byte, or if RLE is applied to a 0×80 byte, does it just affect the first value in the table, or do both get repeated etc.
Here are some screenshots, they’re not quite as good as ElSemi’s, probably due to a bug in the code I’m using right now. Also I’ve had to disable the text layer palette for now because MAME can’t handle over 0×10000 colours in a palette without custom drawing functions.

Click to expand...