First thing to do is see whether Yabause can play the whole thing, as that'll make finding your text routines and other important thingies much easier. :laugh: Check out the Yabause wiki, this info is pure gold.

You'd be looking for answers to the following questions first:

1. Is the game's text encoded in SHIFT_JIS, or another encoding scheme? Do a memory dump of RAM (0x00000000~0x06100000 should cover all the essentials) when a text string is onscreen and see if you can find it in SHIFT_JIS. Couldn't hurt to toss the RAM output in TiledGGD or Tilemolester and look for a font sheet either.

2. Is the game's text compressed? Assuming you've successfully identified the text string in RAM, the quick and dirty thing to do is just open up your game CD in a hex editor and see if you find the string. You could also do things the more sophisticated way and set a write breakpoint on the RAM address you found in Step 1. It may vary from game to game, but I've found the Saturn registers pretty generous in telling exactly where the original game files are stored in RAM. The process goes something like this: the game engine loads the original file to a certain address in RAM, reads from that file, does any gobbledegook it needs to, and then writes the result to the address you found in Step 1.

3. Figure out the text decompression routine (if there is one), and hopefully it'll be something simple. If it isn't, either give up the project or grab a beer and watch the decompression routine play out in SH2 Assembly language over and over again 'till your eyes bleed and you finally figure it out at 4AM some morning. Fun, fun, fun!

4. How many text elements appear as images, and are therefore not directly encoded as text? Yep, this is why translation teams usually know lots about image compression routines too. You may actually want to tackle this before the text to get an idea of how difficult the project is going to be overall. Yabause has a really snazzy feature where it tells you the RAM addresses of all onscreen imagery, relative to the base address of the RAM segment it's in. E.g., VDP1 RAM (often 4bpp sprites) starts at 0x05C00000 in Saturn RAM, and VDP2 RAM (often 256 color images) starts at 0x05E00000.* This is for the post-decompression data, if it goes through that process; you can do a write breakpoint as described previously to trace it back to the original file or watch the decompression routine do its thang.

*Note about Saturn RAM addresses: in some situations that I'm still trying to wrap my mind around, it's most proper to specify them with a 0x2 filling the first byte in the address. So 0x05E00000 becomes 0x25E00000.

Compression is liable to be the main thorn in your side, anyway. You interested in learning some algorithms?

Also, see if Gemini, Nyxojaele or Esco pop in with some SOTN-specific advice. I wonder just how differently the Saturn version handles data from the PSX version? And whether knowledge of the PSX version will help you predict what you need to do with the Saturn version? That'd be really interesting to see. I also distinctly remember there was a Castlevania fan dumping sprites right and left from the Saturn version a few years back. I want to say Abbadox, but my memory's fuzzy.

Whether a text insertion will ever get done probably depends on your own willpower, seeing as nobody's taken it up yet. I think it's a worthwhile project though. I was always partial to Maria's kung fu. While I absolutely can't take on any more projects, I'd be happy to guide you step by step here at the forum, and others will pitch in with the technical explanations no doubt. The Saturn's a beautiful system, so it can't hurt to generate more interest in modding its games.

The psp version seems to have some if not all the extras and more of the saturn version. I was playing maria just the other day and it has a special boss fight vs her.

are the extra areas included as well in the psp?