Grandia English Patch

Translating Grandia 1.1.1

Download
Overview Updates (11) Reviews (1) History Discussion
So I am still working on this. The main focus right now is on the menus. I'm starting with the Save menu and I've found out the following:

  • The SVLD.BIN file is what controls the Save and Load Screen. It appears to be uncompressed.
  • Save File names are not Stored in SVLD.BIN. They instead come from the Script in the MDT files.
  • There is a hard limit on the size of Save File names of 14 characters. This is the exact amount that will fit in the space available when using the 16x16 font.
  • The 8x16 font can still be enabled with the control code 0x03.
  • Using the 8x16 font will let the SVLD screen have more than 14 characters for a save file name, but even if you use it in the MDT file and extend the sizes accordingly, the game will crash when it loads an area with a Save Point that has a Save File name larger than 14 characters.
  • If the Script Header portion of the MDT files has a value of 0xE001, that code corresponds to the Save File Name.
  • The SVLD.BIN file is loaded into HWRAM at the offset 0x060B2000
  • The the pointers in the SVLD.BIN file for the text values are the HWRAM offsets, not the file offsets.
  • The text for the menu is drawn on VDP2 layer NGB3.
  • The text is written to VRAM bank A0.
So with this info there the following issues and concerns:

  1. The 14 character limit is going to be a problem as some of the English scripts names for these files go beyond 14 characters.
  2. If we go the route of using the 0x03 control code size expansion is going to be a must. I've looked into this and I think it's possible but it's going to be a bit painful as it's most likely going to involve scanning SVLD.BIN for all pointers to each specific text value for the screen and updating them all as we expand the size. Not hard, but it needs to be perfect to work.
  3. Another route is changing the Save Load screen to use the 8x16 font by default. I've looked into this as well and it does give us enough space that size expansion may not be necessary outside of character names and one or two odd messages. However there is a snag here. While I can change the font, this screen seems to handle spacing a bit differently. If I just change the value to use the 8x16 font, I get this:
    PjChcpM.png
  4. With additional changes that control the spacing I can get it down to this at least:
    2Yg5z7b.png
As you can see, there's still graphical garbage at the end of every bit of text. I've tracked it down and it looks like the game isn't blanking out as much of the buffer it uses to write each line, so garbage is getting into VRAM. When you use the 0x03 code this doesn't happen. You can also see that the highlighting bar isn't going the full width it should be.

So I need to figure out how to fix these issues. If anyone wants to try messing with this, here's the values you need to change to enable the 8x16 font. Values are the offset in HWRAM, values for the SVLD.BIN file are in parentheses.:

0xB4DC9 (0x2DC9) = Change the 02 to a 01.
0xB37F7 (0x17F7) = Change the 02 to a 01.
0xB3E94 (0x2E94) = Change the 00 to a 01.
 
Last edited:
I think my thought on this right now is it might be best to make a text lookup table of all possible save locations in an unused RAM location. (Expand some standard file thats always in memory). The mdt filenames are modified to contain the 0x3 code followed by the indexes to these locations. Then the code that handles printing the names will, after seeing 0x3, start reading the text from the mdt file’s offset to write to the screen. Spacing should be fine, no corruption, and no crashing.

This means the save data will not be expanded, which gets rid of the issue of having to remap all of those pointers. Also helps in making the save data format remain mostly compatible with grandia digital museum (when/if that gets translated)
 
klarth said:
I think my thought on this right now is it might be best to make a text lookup table of all possible save locations in an unused RAM location. (Expand some standard file thats always in memory). The mdt filenames are modified to contain the 0x3 code followed by the indexes to these locations. Then the code that handles printing the names will, after seeing 0x3, start reading the text from the mdt file’s offset to write to the screen. Spacing should be fine, no corruption, and no crashing.

This means the save data will not be expanded, which gets rid of the issue of having to remap all of those pointers. Also helps in making the save data format remain mostly compatible with grandia digital museum (when/if that gets translated)
Click to expand...

So that could work for the save file names. Though something like that is probably beyond my skillset to be honest.

Though for some parts that are stored in the SVLD.BIN file we might still want to look into changing the font as there might not be enough space to have it point to an offset with the 0x03 code. For example Save and Load both only have 4 bytes available which might not be enough for a memory pointer and the 0x03 code depending on where it ends up at.
 
This is all really cool stuff! It looks like you've made amazing progress.

In case it's any help, I did a little research on the FMV format last year and wrote up my notes here. It's stored in a Quicktime container, but some of the metadata in that container is misleading. The video is an unknown codec, but by appearance possibly an MPEG-1 variant decoded in software. The audio is CRI ADX, and is standard; if you extract that from the video you can play it back with anything else that supports ADX.
 
So I figured I'd post an update. I've still been working on this and I've now successfully translated the following:

All Menus (Save/Load, Config Options, Items/Equip/Magic/Moves/Status, Shops, Item Get, etc.)
All Items
All Monsters and their attacks.

These have been done by pulling the data out of the Playstation version and injecting it into where it needs to go into the Saturn version. For the items this wasn't too hard as I just needed to put the English data into the file and adjust the pointers. For the monsters it was a bit more painstaking as there was no consistent pattern and all 200+ monsters had to be manually changed.

Menus I was able to somewhat automate it with a tool that looked for pointers/offsets in the BIN files for those screens, and then updated those values based on the new data I wanted to put in to replace the Japanese text. This worked successfully for the most part, with only a few files needing hand adjustments afterwards. I'll be committing these tools to github after I take some time to clean the code up a bit.

Here's some screenshots to show the progress:

toJoiMQ.png


lBQLhbI.png


BUgt2Xe.png


aQ72KST.png


6UnqiWh.png


wwPzUpU.png


yeRaJmt.png



However I have hit a snag. It seems that the English PS1 version created additional MDT files for some areas where the text was too big to fit into RAM. Basically the created a duplicate file from a parent MDT file, and put the overflow text into that one. This new file then takes the place of the original after certain story events have happened.

I've looked into the possibility of recombining these files but I'm not sure if it will work as we may hit the same problem. So I'm curious if it's possible to do the same thing the PS1 version did and create these clone files and find a way to make the game use them. However that's probably going to take some time to figure out.
 
EDIT:

I realized I forgot to post some battle screenshots:

EFDN2gW.png


5YCciuF.png


LFyxKiq.png


KayNalE.png


4RCGFQg.png


oeiMBFq.png


So I did some more digging and I have at least found what the game uses to know which MDT file to load when you change areas. At offset 0x06029A00 there's a table that lists all the files on the CD, with a value for what sector it's at, and how many bytes it is. The game references this when it wants to load a new file. How it knows which file to get out of this list though I don't know yet.

However, I have been able to play around and have the game load different areas for me by changing the values for one MDT file to be that of another. So by doing this I was able to go from the Port of Parm to New Parm and test out the magic shop screen:

eVJX3l5.png


Unfortunately this screen got modified in the English PS1 version, so some of those translations either wont fit or don't make sense, so I've had to improvise a bit here. I also tested out the buy screen and found I missed a word in the trade screen:

eZIl8Tr.png


Finally, just for fun I took Sue on a date to the Pirate Island. The game went a bit bonkers, I can only imagine because characters that should be in the party weren't there, and characters that shouldn't be in the party were there. The game eventually crashed when invisible Feena tried to speak after Justin spoke on behalf of a mermaid:

nUfOc61.png
 
Last edited:
So I may have a work around for the issue of the PS1 version having more files due to a bigger script. I found out where the game determines what map to load next. It reads a value from a table in the MDT file, which is at the offset found at 0x30 in the MDT Header. That value tells it which map to load. However instead of updating every MDT file, I decided to take a stab at adding some code to the game, as it looks like this is what the PS1 version did as it's MDT files are unaltered at those offsets.

For the time being I've added code that will check what file the game is loading. If it's loading any of the files that have clones for more script, it's going to check the scenario table which lives at 0x06021DC0. If the value is greater than or equal to the bare minimum for the overflow file, the code will change the file name to the new file. Otherwise it will continue loading as normal.

So far I've tested this with success on the first new MDT file, 2001.MDT. This file should be used in Parm starting the day after you get back from the Sult Ruins. Using Debug mode to change the flags, I've able to confirm that this code works correctly, and so far no unexpected bugs have arisen from it. I have the code ready to go for the other files, I just need to find out what Scenario flags need set and what values they need set to and it should be good to go.

Next, the remaining battle text that needs translated is not actually stored as text at all. It's actually graphics that need edited. However it looks like the data for those tiles is compressed. I've tracked the data down to MGDAT.BIN file in the BATLE directory, but I'm not experienced enough to really identify if it's a common compression format or not. This data encompasses the text for the icons in the circular battle menu, the text for the headers in the Items, Magic, and Skills windows, as well as the AI windows. If someone wants to take a shot at looking into this feel free to do so, I've attached a RAM dump and disasembly of where I think the decompression is happening. However, I have done some work on translating the post battle screens which had their tile data stored uncompressed in the ENDW.DAT file:

l0giqkW.png


nmcA48K.png


9YGPNkI.png


Some of the tiles I didn't touch yet though as I didn't feel skilled enough to make something that looked good, nor could I find a font I found acceptable. So if someone wants to take a shot at that feel free to do so. I was a bit limited in space though, hence why it says EXP Points Won instead of Earned. The way the tiles are stored I couldn't get the lower case e to turn out right as the game is hardcoded to read the tiles in a specific way, and I haven't had the time to look into modifying that.

Finally, I've also looked at editing the text in the Map screen. This is also graphics instead of text, and it's stored in the AMAP#.ADD files in the FIELD directory. However I think I'll need a graphics artist to deal with this. This text is drawn as VDP1 scaled sprites. I tried using a 32x32 font I found from Pokemon Stadium on ROMHacking.net, but no matter what I tried it turned out looking like crap when VDP1 scaled it. It looked fine in the tile editor though. You can see how it looked here:

Yx1T98p.png


I think though that once I get the other scenario flags sorted out, I should be close to at least having a beta version patch for Disc 1 ready for people to play test.
 

Attachments

I think I've finally got the bugs worked out of my code that causes the game to load the new MDT files when the right events happen, however I still need to figure out the actual scenario flags for the later areas. If anyone who feels up to it wants to help, one thing that would be really helpful here is game saves to use with Mednafen or possibly Yabause. I need saves before, during, and after the following events:

1) Feena gets kidnapped in New Parm
2) The Rain Event in Dight before Typhoon Tower
3) A save around Gumbo after the Twin Towers events.
4) Sue gets Sick in Dight

If I can get saves before, after, and during these events it would be really helpful in figuring out the scenario flags. Otherwise I have to play through the game myself to find them. Which I don't mind doing that, but it is time consuming. So if others already have saves at those points to share or can get there quickly that would be great.
 
Hey Trekkies. Signed up just to comment on your great effort. You have made incredible progress in what I always considered a "dream project" (Saturn Grandia in English).

Keep up the amazing work, I will keep tracking the advance this way.

I don't have save games for the Saturn version (due to the Japanese blocker) but if you need any other testing I could try and help.
 
aaarrrtvvv said:
Which version are you translating? I hope it is slightly bugfixed "Grandia - Memorial Package"
Click to expand...

It's the one I have which is the original release I think. If I can get a hold of the Memorial Package version I can take a look and compare rips and see what's different. For most of this though I think the changes should still carry over and work, unless they completely changed the file formats.

Do you happen to know what bugs were supposedly fixed?
 
I would be very surprised if there are bug fixes between the original release and the Memorial Package. Nothing currently online in English or Japanese - including Game Arts's own website - indicates any difference other than initial price and packaging, so that would be a pretty significant (re)discovery.

The Memorial Package even has a warning on the back of it that states「ゲーム内容は従来の物と全く同じです」which means "the contents of this software are completely identical to the existing release".
 
Last edited:
Ms. Tea said:
This is all really cool stuff! It looks like you've made amazing progress.

In case it's any help, I did a little research on the FMV format last year and wrote up my notes here. It's stored in a Quicktime container, but some of the metadata in that container is misleading. The video is an unknown codec, but by appearance possibly an MPEG-1 variant decoded in software. The audio is CRI ADX, and is standard; if you extract that from the video you can play it back with anything else that supports ADX.
Click to expand...
Are you sure that the final resolution is 352x144 in Intro Video. That you based in the Grandia output is 480i? But not is correct. The real output is 448i, but the resolution set is 352x244.
 
So I've hit a point where it looks like the PS1 version changed the portrait codes, so I need to go in and fix them. In doing this though I've figured more out about the control codes and figured I'd post an update that had what I already knew plus some new stuff.

A text sequence in the MDT file usually will start with the HEX value 0x1001. The next bytes vary and I'm not entirely sure what they mean, but the next one of importance will follow the pattern 0x3XXX. This Byte represents the distance to the end of the text sequence, minus 3000. So if you see 0x301A for example, it means if you move forward 0x1A bytes you'll be at the end of the text sequence. Following these bytes, things can vary. Sometimes there's nothing and we go straight to the next significant bit of information, other times there's a lot more data here. My best guess is that this is for setting up specific scripted sequences like fade ins and what not.

The next significant bit of data is the bytes that follow the pattern 0x2XXX or 0x9XXX. This value represents the distance to the end of this bit of text minus 0x2000 or 0x9000 respectively. Then here is where we get into the fun stuff. The next bytes are completely optional so they may not always be there depending on what's happening. But they follow this pattern:

Code: 
02 0F 03 0A 0C 0001

This however is just for one specific type of portrait and text box. So it really follows this template:

Code: 
TT 0F Xx YY 0C 00PP

TT = The text box type or position. I've found that the following values are valid:
  • 0x02 - Regular Text Box Positioned on the bottom of the screen
  • 0x05 - Prompt Text Box (The kind when you need to make a decision)
  • 0x06 - Sub-Box (The smaller text boxes that can overlap the bigger ones for quick interjections).
  • 0x08 - Regular Text Box positioned on the top of the screen
If this byte isn't provided, the game defaults to a regular text box positioned on the bottom of the screen.

0F = A portrait is going to be used.

Xx = Horizontal Position of the Text Box. The nibbles in this byte actually mean different things.
  • X represents the screen orientation. 0 = Left, 1 = Center, 2 = Right
  • x controls fine positioning of the portrait in tiles. You almost always see this byte set as either 03, 12, or 21
YY = Vertical Position of the text box. This is almost always set as 0x0A.

0C = Special settings for the font. Playing with this does weird things to the font from changing it back to the 16x16 after I modded the game to use the 8x16, drawing it with a different palette, etc. The game almost always has this set to 0C.

00PP = Portrait code. This value determines what portrait to draw. Valid values are 0x0000 up to 0x003E. 003F and higher will crash the game. These values are not consistent across the game, they change from map to map.

Following these bytes the game will have it's text written based on the values in the font table. Any of the above control codes can pop up in here to have the game draw new portraits, change text boxes, etc. Additional control codes you can see in this sequence are the following:

0x01 = New Line.
0x03 = Use 8x16 Font
0x04 = Use 16x16 Font
0x07 = End of current Text.
0x0E00 = Pause for a moment. Usually used when syncing with dialogue.

After the text is finished, there's usually some additional data before we either hit another bit of text or the end of the text sequence. More text will follow the above format starting with either 0x2XXX or 0x9XXX. The end of the text sequence is denoted with 0xF000.
 
Ok everyone, I believe I have all the event flags figured out. So with that out of the way I think we're ready for Disc 1 play testing. The image I've used for this is a Rip from my personal copy of the game, so hopefully the patch will work for the rest of you if you rip your own copy using ImgBurn like I did. If not we'll cross that bridge together.

The patch is in xdelta format, so you'll need to use a program like DeltaPatcher or DeltaPatcher Lite to apply it. I've provided a patch for both the BIN and CUE file, but in the event the CUE file patch doesn't work, simply use SegaCueMaker to generate a new one.

This is a very early release that is intended for Beta testing only. The goal here is to catch any hard crashes or severe bugs in the game, as it's still likely that could happen. While I've caught a few myself, I don't really have the time to fully play through all of Disc 1 multiple times trying various different things. Hence why I'm releasing this early patch.

So if you want to Beta test, download the patch and apply it to your image of the game. I would refrain from burning this to a disc just yet as crashes are still very likely, and I wouldn't want anyone to waste good quality CD-Rs. For now I'd stick to emulators. The emulator of choice for this is Mednafen. It seems to behave the closes to a real Saturn. SSF is a good second, though there are instances where a real Saturn and Mednafen crash, while SSF doesn't.

If you encounter a crash or bug, please provide the following information in this thread:
  • What exactly happened? (Game Crashed, Typo, Garbled Text, etc.)
  • Screenshots or Videos if possible.
  • What where you doing when it happened?
  • Where in the game where you when it happened?
  • A copy of your save file from your emulator.
Aside from the possible crashing, the following issues are known:
  • Voice Audio is horribly out of sync during voiced dialogue.
  • The words "Ambushed" and "Your Initiative" in battle are out of alignment.
  • Battle Menu Icon text is not translated. This is actually Graphical data that needs to be decompressed and edited.
  • Some Post Battle text is untranslated for similar reasons.
  • All but the first Map Screen are untranslated. The text in these screens gets scaled by VDP1 which ended up looking very poor. As a result I have not touched the others until I can figure out a better way to do this.
  • FMVs are untranslated. The format used for these is still unknown so these most likely wont be subtitled for a while.
  • Menu Selections are misaligned (Yes/No on Save Screen, etc.)
If this thread becomes too cluttered, I'll create a testing thread.
 
Last edited:
So after some testing it seems my Rip for the original disc wasn't good. I've since gone back and ripped the disc again 3 times at the lowest speed and all three are identical. So I think this one is safe to use. I've therefore taken down the old patch and uploaded a corrected one.

EDIT:

So at zyrobs suggestion I've reworked the patching process to include extracting the Data and audio tracks from the BIN file and patching the data track separately. This should make the patching more reliable. The README file has been updated to explain how this patching works. Anyone who's done the Policenauts translation should be familiar with this. Basically it works as follows:

  1. Rip the game as a BIN/CUE using ImgBurn
  2. Download and install IsoBuster
  3. Use IsoBuster to extract the 2 tracks from Session 1
  4. Apply the patch using DeltaPatcher or DeltaPatcher Lite to the extracted ISO track.
  5. Rename the Tracks to GRANDIA.iso and GRANDIA.wav repsectively
  6. Use the included CUE sheet to play the game in an emulator or to create a new BIN/CUE or to burn it to a disc.
 

Attachments

Last edited:
  • Like
Reactions: vbt
You must log in or register to reply here.

Similar threads

D
Duck TrueMotion help
Replies
2
Views
552
David Gámiz Jiménez
David Gámiz Jiménez
benclaff
Translating Culdcept: tutorials, notes, whatever
Replies
7
Views
2K
Malenko
Malenko
cww80
Sword and Sorcery/Lucienne's Quest.
Replies
2
Views
811
dibz
dibz
Malenko
Lets translate Puzzle Logic Rainbow Town
Replies
11
Views
931
Malenko
Malenko
Malenko
Saturn 15bpp tool tutorial
Replies
4
Views
462
Malenko
Malenko
Back
Top