What to do when your game has 2 byte characters but only want 1 byte input to work?

[PSXCraver]

Sounds complicated. But I know it can be done.

I am working on a PSX game, and I will need to do some ASM in order to achieve my goal.

The game is: Khamrai.

I did a lot of research out there, and I have found a lot of details about how to do these hacks. But, I still failed to grasp how getting any of it to work?
What I want to do is save space with Character inputs. Since, Shift-Jis takes way too much room, and that makes it impossible to really translate anything.
The goal is to get 1 byte character excepted instead 2 byte, to save space.
I already know that I need to make a save state and open it in Hex editor. In it, you see when the RAM comes in memory. The only real problem is; How to use this information?

By what I had witnessed, you are supposed to subtract the RAM value to something like the file size of the ROM? It might be it. But as a rookie to this, it's a bit of a blur.

I probably need more explaining, but this is the best I can do right now.
Any ideas?

I would really appreciate your help!

 

[FAST6191]

Generally this sort of thing is not advised unless truly necessary -- memory issues (either holding in RAM or ROM storage, the latter being unlikely on a PS1 game) and lack of characters (hard for a Japanese game, usually more people wanting to expand English games for other European languages with characters having accents and whatnot). To that end if you can deal with pointers.

Two main approaches possible.

1) If you are lucky the game's font file or similar will have the character definitions embedded within it. I don't tend to expect this for the PS1 (Windows has been using it for decades but consoles were rather slower on the uptake here and I don't usually expect it until the DS era, and even then it is not assured) but if you have it then makes sense to use it. If it is in the font then great, if not and it is not obvious then onto 2) and you might end up back here if your analysis in 2) allows for it.

2) The traditional way.
The game's text engine will somehow know to go to the text file (I assume you can find that for these purposes, though for the PS1 it might well be a copy of it in RAM that gets used rather than reading from the ISO).
From there it will read presumably 16 bits, decode what that is*, place it on screen, repeat for next character and on and on. It might also count the bytes read and know to start a new line/text window at a given point so you will potentially also have to sort that, this can be both in normal text and is pretty much the definition of fixed length text like you might occasionally encounter in menus or something. You get to change all of that, though most will do the minimum stuff to just get it to attempt to decode 8 bit and then see if there is any fallout to fix.
This would probably also go a lot better if you know your PS1 era C family decoding and sorting methods, though you can probably muddle through without them -- it is new enough that you might be seeing some more exotic methods of data fiddling, though will probably be spared modern X86 branch prediction aware stuff.
If it is in RAM then find where it lands in RAM (hopefully is just a matter of dumping the memory and comparing against the file from the ROM, or decompressed version thereof if it is that) and set breakpoints there (presumably a break on read). If it is in ROM (unlikely for the PS1 or anything optical/floppy drive based, common on other consoles prior to the DS) then set breakpoints on that instead, or if the RAM dump approach is not working for the PS1 then set it here and follow it along until it lands in RAM.

*some games might have other things embedded in the text engine for formatting, for new line, for end of section/continue text/auto continue, for yes/no constructions, for placeholders ("it costs ? per night to stay here" sort of thing), for lengths and for all sorts of other things, some might even combine 8 and 16 bit and leave 8 bit stuff for formatting. To that end it could be a bit more complicated than a simple lookup, for the 8 and 16 bit combined stuff you will tend to find the first bit or something is used as an indicator (if high then do 8 bit decode, if low then do 16 sort of thing, though can be random bits within it, can be longer than that and can be more of a range affair)

 

[PSXCraver]

Generally this sort of thing is not advised unless truly necessary -- memory issues (either holding in RAM or ROM storage, the latter being unlikely on a PS1 game) and lack of characters (hard for a Japanese game, usually more people wanting to expand English games for other European languages with characters having accents and whatnot). To that end if you can deal with pointers.

Two main approaches possible.

1) If you are lucky the game's font file or similar will have the character definitions embedded within it. I don't tend to expect this for the PS1 (Windows has been using it for decades but consoles were rather slower on the uptake here and I don't usually expect it until the DS era, and even then it is not assured) but if you have it then makes sense to use it. If it is in the font then great, if not and it is not obvious then onto 2) and you might end up back here if your analysis in 2) allows for it.

2) The traditional way.
The game's text engine will somehow know to go to the text file (I assume you can find that for these purposes, though for the PS1 it might well be a copy of it in RAM that gets used rather than reading from the ISO).
From there it will read presumably 16 bytes, decode what that is*, place it on screen, repeat for next character and on and on. It might also count the bytes read and know to start a new line/text window at a given point so you will potentially also have to sort that, this can be both in normal text and is pretty much the definition of fixed length text like you might occasionally encounter in menus or something. You get to change all of that, though most will do the minimum stuff to just get it to attempt to decode 8 bit and then see if there is any fallout to fix.
This would probably also go a lot better if you know your PS1 era C family decoding and sorting methods, though you can probably muddle through without them -- it is new enough that you might be seeing some more exotic methods of data fiddling, though will probably be spared modern X86 branch prediction aware stuff.
If it is in RAM then find where it lands in RAM (hopefully is just a matter of dumping the memory and comparing against the file from the ROM, or decompressed version thereof if it is that) and set breakpoints there (presumably a break on read). If it is in ROM (unlikely for the PS1 or anything optical/floppy drive based, common on other consoles prior to the DS) then set breakpoints on that instead, or if the RAM dump approach is not working for the PS1 then set it here and follow it along until it lands in RAM.

*some games might have other things embedded in the text engine for formatting, for new line, for end of section/continue text/auto continue, for yes/no constructions, for placeholders ("it costs ? per night to stay here" sort of thing), for lengths and for all sorts of other things, some might even combine 8 and 16 bit and leave 8 bit stuff for formatting. To that end it could be a bit more complicated than a simple lookup, for the 8 and 16 bit combined stuff you will tend to find the first bit or something is used as an indicator (if high then do 8 bit decode, if low then do 16 sort of thing, though can be random bits within it, can be longer than that and can be more of a range affair)

Wow! Thank you for the very detail post.

This was very informative, and will be helpful for my goals.
Appreciate it very much!