[_dk]

Hi all, I just started romhacking a few days ago, and have been tinkering with an old PSX game called Kowloon's Gate that has never been translated. I have managed to find where most of the script is stored. I also tried inserting some preliminary translations back into the game, and this is how it turned out:



Looks passable for a first try, but the beginning of the line is cut off and there should be a line break somewhere in there. My actual question though, is I'm wondering if I'm doing this correctly, since I've been doing it like this:



Since the game was coded in S-JIS and used a double-byte character set, I have been padding 00 to every ascii character that I reinserted. Not only is this a hassle to type, I worry that I'll run out of space if I have to use 2 bytes for every English character. What's the common approach to solve this?

Also, is there a more efficient way to insert the script back into the game? I've found solutions like Thingy and Atlas, but they don't run on my 64-bit machine.

[mz]

What's the common approach to solve this?

You have to learn MIPS R3000 assembly to modify the game's code so it uses only 1 byte per letter.

I've found solutions like Thingy and Atlas, but they don't run on my 64-bit machine.

Atlas works fine in my Windows 8.1 64-bit machine. You probably don't know how to run "command line" programs, so you may need to learn that too.

So... Besides that, you should also learn about pointers, how to reverse engineer that PAK file format (likely a custom format, so I wouldn't waste too much time searching around the web) and how to add a "variable width font", if you want to make it look prettier (less empty space around the "i" letter, for example).

Good luck!

[_dk]

You have to learn MIPS R3000 assembly to modify the game's code so it uses only 1 byte per letter.

Is there anything specific I should look for? As in, is there a specific register that the game's code write to that sets how many bytes to use?

Atlas works fine in my Windows 8.1 64-bit machine. You probably don't know how to run "command line" programs, so you may need to learn that too.

Oh! Thingy didn't work in cmd and somehow I didn't try to use Atlas there, turns out Atlas runs fine in cmd!

Thanks for the answers! This is gonna be a long journey.

[STARWIN]

Is there anything specific I should look for? As in, is there a specific register that the game's code write to that sets how many bytes to use?

No, you really have to be able to read and understand the asm routine/routines related to this. Registers tend to be more boring than that - just temporary storage for calculations. The "specific" part here is that you have found the text that is used in this part of the game. So when using a debugger emulator like no$psx you know that the memory location where this file is loaded (specifically this text is loaded) is then read by code that is either the code you are interested in, or related to it (because it would supply the text data to the code you are interested in).

A subproblem here is in how to figure out where the text you know in the ROM is loaded in the ps1 RAM (I think most things being executed/read in the ROM have to be loaded to RAM in order to be visible for the processor in its address space). So the simplest approach would be taking a RAM dump while the game is close to the state where it outputs that text, and search the RAM dump for this data to get its offset. I don't know if anything allows it this directly, so I guess some people use save states instead (and in that case you have to know how the RAM maps to the save state). The other approach would be understanding how the game loads data (files) from ROM (filesystem) to main memory (RAM) and follow the path that way.

When you have the RAM offset of the text, standard hacking can begin. So set a read breakpoint and wait until the game starts processing the text.

Eventually the text is then printed on screen, and if you are familiar with the graphics subsystem, that could be an alternative approach to figuring out where the code of interest is.

disclaimer: i'm not a translation hacker and somewhat new to ps1, so if anyone else has some other/better approaches or corrections, i'd like to hear those

[KingMike]

I'm pretty sure non-ROM-based media (CD, floppies, etc.) can't directly execute code, so yes, the code from the "ROM" (or ISO, as it's usually called) must be loaded to RAM before it can be executed.

The little I tried in PS1 hacking, was using PCSX Tracer or something, and documents recommended hacking savestates (I guess recommending PCSX because the savestates were essentially renamed zip files, making them easy to uncompress for hacking), as until the game needed to load anything else from the CD it was sort of like hacking a ROM-based system.
(and then of course, once the hacking has been tested, finding the original data in the ISO and replacing it)

[mz]

There's this newbie-friendly guide where the author explains how he changed Policenauts from 2-byte characters to 1-byte:
Part 1: https://web.archive.org/web/20091016201648/http://slowbeef.com/romhack/pnhack1.html
Part 2: https://web.archive.org/web/20100115051206/http://slowbeef.com/romhack/pnhack2.html

Actually, I think Part 2 has everything you need, but you might need to read Part 1 first to understand it better... I can't remember now.

[_dk]

You have no idea how much I love you right now 

Since part 2 stops just before he writes the assembly code, I found part 3 archived on the server. Part 4 to 6 also existed, but the archived version for those are incomplete and or even 404'ed.

Posting this here for convenience:
Part 3: https://web.archive.org/web/20100603235758/http://www.slowbeef.com/romhack/pnhack3.html

[tryphon]

Could be interesting to archive all of these pages somewhere
, for example on datacrystal wiki.

[Gemini]

The trick with most PlayStation games is that they all use similar code, unless the developers went full retarded or highly optimizing. In other words, what I would suggest is to study a bit system libraries and sprite/polygon primitive formats, that's what a good chunk of titles uses to draw text via separate primitives or something akin. In order to figure that out (i.e. how game draws text), the pSX GPU debug capture comes to help, same for no$psx. Use either and combine them with write breakpoints to track the exact code, then walk backward to see where data is coming from. That approach is 100% guaranteed to give you the expected results.

[_dk]

I have tracked down in assembly the routine that puts the text onto the screen.



Since I want to have the game read 1 byte instead of two, I want to have the game automatically add 00 in front of the bytes. In slowbeef's tutorial he needs "80" in front of the bytes, so he just added 8000 as an intermediate. This doesn't work in my case because adding 0s does nothing, and I don't think bitshifts are the solution either.

I came up with the solution to just load 1 byte into the register and then let the game continue to store 2 bytes into memory where the text will show on screen, assuming that the extra byte should be 00 by default.
So on line 00038c40, just change lhu r6, 0x0000(r5)  to lbu r6, 0x0000(r5)

Needless to say, this didn't work (or I wouldn't be posting). This messes with the branch on the next line, and even if I get rid of that branch, the correct text still doesn't show.

Any ideas? 

[Gemini]

If the game is simply copying your text into another buffer, then lbu and r5+1 might do the trick. Most games however work right away with whatever is in ram, so slowbeef's trick isn't really that useful as a general rule.

Anyways, in your case the game is performing some extra checks that require you to load a 16 bit value (see 0x38c5c, that's checking if text is 0x1E00). You're going to need more than a simple change there, possibly rethink a good chunk of the text reader to account for all 8 bit reads.