Langrisser III Translation

I figured it's been long enough, and it's getting irritating at how no one seems to recognize the langrisser series.

So i've started a site dedicated to get the ball rolling and start getting the langrisser series 1-5 translated(though i'm currently working on langrisser III myself).

For anyone who's interested:

Cyber Warrior X
Thats really cool that you are looking at the langrisser series. I dont know if you want to think about it until you look at langrisser 3, but i started a table file fo langrisser4. I was also able to find and replace text. Though i could never figure our which file(s) contained text, instead i just split up an iso image and edited that way, rejoining the files when i reburnt and tested it. If you are interested, you can get the table file here: and i guess i could answer any quick questions, but i have a feeling you could figure stuff out just as quick. The thing that stopped me from looking at the game too deeply was that i couldn't find the font in the game though a random chunk of asm code in ascii seems to define system.dat as a fontdatafile. Here is an excerpt that might provide hints if you are wondering what some of the files are for:



.align 2


.ascii "SYSTEM.DAT "


.align 2


.ascii "SCEN.DAT "


.align 2


.ascii "MAP_C.DAT "


.align 2


.ascii "MAP.DAT "


.align 2


.ascii "TITLE.DAT "


.align 2


.ascii "MAGIC.DAT "


.align 2


.ascii "CLEAR.DAT "


.align 2


.ascii "SND00.BIN "


.align 2


.ascii "SND_DAT.BIN "


.align 2


.ascii "MAGSND.BIN "


.align 2


.ascii "BGM.BIN "


.align 2


.ascii "BAR.BIN "


.align 2


.ascii "BTBGM.BIN "


.align 2


.ascii "TK_SC.BIN "


.align 2


.ascii "BTSE.BIN "


.align 2


.ascii "BTBGS.BIN "


.align 2


.ascii "AREA.DAT "


.align 2


.ascii "CUR.DAT "


.align 2


.ascii "STAFF.DAT "


.align 2


.ascii "COL.DAT "


.align 2


.ascii "BASE.DAT "


.align 2


.ascii "BASE2.DAT "


.align 2


.ascii "OPEN1.DAT "


.align 2


.ascii "OPEN2.DAT "


.align 2


.ascii "OPEN3.DAT "


.align 2

I hope something has helped you, or at least comforted you in that someone else has looked at the game before. I know you have had quite a bit of experience with SNES programming/hardware, so i am optimistic about your projects and i wish you the best of luck.
Actually, that helps me quite a bit. I hadn't found the font file for langrisser IV yet, though I had my suspicions as to how similiar both games were in that regard. Looking at the table file, it almost looks like what my langrisser III table will look like(or what I suspect it should look like, I just have to go write it and cross my fingers).

Hmmm... As for system.dat, it's pretty big to be a font file. Unless only part of it is used for the actual fonts, and the rest for whatever. I'll have to check that out.

The only real experience I had with snes coding, etc. were the docs and the code I studied, not much more then that. (most of my work on snes9x and openspc was fixing up ui bugs, and making other general improvements to the ui)

Actually, what kind of tool did you use to get that asm code chunk? Obviously it's one missing from my box of tools. Once again, thanks alot.

Cyber Warrior X
As i mentioned before, the hacking i did on the game was done by working with chunks of the iso in a hex editor. While looking around, i just happened to find that huge block of asm source code in plain ascii. I have no idea what file it came from or why it was there.
I got a sizable chunk of asm once by going through the 0.bin of the game Hexen. I don't remember specifically why I was doing this...
Sorry for waiting a week to reply :/

Though here is the answer to your question, and all i know about langrisser4. All the addresses given are as they would be displayed viewing the entire iso in a hex editor. The ascii chunk of asm code is located at 0x12C020. I think there is a block of text starting at 0x177800 and ending at 0x18640B. In this block, the word "option" from the title screen can be found at 0x178362. For this section, things seem to be ended with FFFF. I don't know if its acting as newline marker or an end of string marker, though i would think its an end of string. Besides this menu text, i also found the text of the opening woman talking. The first line of what she says can be found at 0x1B19CC0. In this block of text, FFFC seems to be the end of line marker while FFFD is the end of the string. I didn't look much further than this. Though i did notice that it looks in the same place for the start of text implying that it uses pointers. I did not find any of the pointers though.
Figured i'd update the Langrisser III situation, and other tidbits i've learn over the last month.

First of all, the greatest discovery so far has been that Langrisser III and IV both use the same text system! Drewbacca, I managed to do an update to your langrisser IV table to reflect this, and have already managed to get up to 250 kanji done as well (in shift-jis, though, mind you). Anyways, I did find what you were talking about in Langrisser IV with the text. It almost seems as though the font table starts at the begining of the system.dat, and ends somewhere around 0x00008500. Then there's a bit of a buffer, and at 0x00009074 the first text pointer table starts(2 bytes designates the offset of each segment of text).

The actual text goes from 0x000092A0-0x00009F63. FFFF is an end marker for each text segment, with FFFC being an 'end of line' marker, and FFFE as a 'end of paragraph' marker.

Hopefully i'll have my docs at my site updated sometime soon.

Cyber Warrior X

(Edited by CyberWarriorX at 8:22 pm on July 7, 2001)
Wow, making nice progress... unlike myself. If I am forced to quit Grandia, I would gladly be of any service to you. I am knowledgable about many things concerning general ROM hacking, but am now just discovering the joys of 2-byte Japanese text. :)

Curious that the Langrisser coders decided to use 2 bytes for line breaks, etc. Why not use one? Maybe compatibility with Japanese input methods?...
I'll be honest I really don't understand their whole logic to even how they did the font table, but anyways, putting that aside, 1 byte wouldn't be enough for the sheer amount of characters that are used in the game. Most of the time, games usually use katakana or hiragana, and sometimes a kanji character here and there. So their font table is usually pretty small. (1 byte would allow for up to 255 characters) With Langrisser III, they actually managed to use katakana, hiragana, and over 1500 kanji, which of course is far over the 255 limit so they elected to use 2.

And the weirdest part is, they added kanji to the table as they needed it, therefore, there's no particular pattern to follow. Basically i've had to go through each kanji, find it's shift-jis code, and add it to the table(talk about a painful process). Anyways, I do have help from someone who's quite knowledgeable with kanji and japanese in general, so it shouldn't be too much of a problem now.

The only thing I could really use help with now, is possibly someone hacking the main program to allow for a different size font, etc. Though it's no big deal. I have ways of getting around using 16x16.

Cyber Warrior X

(Edited by CyberWarriorX at 8:24 pm on July 7, 2001)


Staff member
This is the way I see it.

1 Byte = 8 Bits = 2^8 = 256 possibilities

2 Bytes = 16 Bits = 2^16 = 65,536 possibilities


4 Bytes = 32 Bits = 2^32 = 4,294,967,296 possibilites

so 4 Bytes is a bit too much and 2 Bytes is the best choice.
I know that one byte is nowhere near enough to represent all of those characters - there are 6,879 JIS characters - but why the two byte line breaks? Just a waste. You could make a script a lot smaller by using one byte breaks (why not just 0xFC, 0xFE, 0xFF?).
Probably because it'd confuse everything. It would have to read each character in at 1 byte each instead, and it'd have to waste time try to figure out if it's only a break, or if it's a regular character. (keep in mind that there's also stuff like 00FE, 01FE, etc.) I can understand what they were trying to do. Besides, when you're using a cdrom, a few thousand bytes isn't going to make a big difference.

Cyber Warrior X