News: 11 March 2016 - Forum Rules

Author Topic: How do I go about translating a famicom disk rom?  (Read 899 times)

AssCheek303

  • Newbie
  • *
  • Posts: 1
    • View Profile
How do I go about translating a famicom disk rom?
« on: April 26, 2021, 06:12:03 pm »
I have limited knowledge of programming and coding, but I'm determined to learn. I really want to translate Famicom Detective Club Part I someday. What I've done so far is opened up the rom in a hex editor and I see a bunch of gibberish. From my understanding, that's the binary code being produced as decoded text correct? Is there some way to "translate" this "gibberish"?

FAST6191

  • Hero Member
  • *****
  • Posts: 3301
    • View Profile
Re: How do I go about translating a famicom disk rom?
« Reply #1 on: April 27, 2021, 10:35:53 am »
FDS games are noted as containing files rather than being one big lump (prior to the DS if it was not on an optical drive or floppy drive it was probably a lump) so you would want to start with that.
I don't know what the suggested tool is these days but http://www.romhacking.net/?page=utilities&category=&platform=&game=&author=&os=&level=&perpage=20&title=&desc=fds&utilsearch=Go should feature a few. Hopefully you get some nice file names, extensions, directory names and file sizes to narrow things down (dialogue.file in a folder called script being overly optimistic but better than those looking at a lump of code featuring game's programming, levels, graphics, music and text, and maybe nothing used at all by the game but left in by the devs).


Somewhere in these probably will be some way the text is represented that you in turn need to alter. It is rarely that simple and at least one of the following things will make life more fun. Said following things include compression, font alterations, pointers, text as graphics (I send you a nice BMP image with some text in it and you can't exactly get a cursor up to edit it),

In the ideal case you would have basic table finding* and pointers** to deal with, and many games from that era are that with fonts being the next thing (Japanese is not a Roman character using language so might not have included them -- when your memory is usefully measured in kilobytes you don't need to be including things you won't be using).

After that http://www.romhacking.net/start/ is there for a reason.


*yeah you are right about it being a binary equivalent. I usually describe it with an analogy to the 1=A, 2=B, 3=C... code most do as kids, just the computery version of that. There are some standard ones (ASCII https://www.ascii-code.com/ , ShiftJIS http://rikai.com/library/kanjitables/kanji_codes.sjis.shtml , EUC-JP http://rikai.com/library/kanjitables/kanji_codes.euc.shtml and of course unicode https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/ ) but games even today rarely use such things and it would be the exception back when. There are all sorts of methods you can use to find tables, some of which don't work as well with Japanese like the otherwise incredibly powerful relative search, that vary in effectiveness and difficulty (assembly driven analysis is going to work every time but requires you know a bit about assembly coding and put the time in, statistical methods like take the text section and analyse letter count and most times it will match scrabble scores, are less reliable but quicker, and that is before we deal with corruption).

**continuing with analogies then computers don't know where things are and don't have the resources to parse text. Computer programs then have all sorts of things to keep track of data, the main thing being pointers which are small values that... point the way to things. For text you might have one every line, every screen or every section. I usually then make the analogy of it being like a contents page in a book. Rip out some pages and if you had counted along you would have done wrong somewhere, stuff a bunch in and the same. Given that translation will seldom ever make things the same size (or shorter such that you can pad it out) you then get to deal with pointers. There are three, maybe four, primary types (that being standard, offset, relative and simple size, and can deal with the ROM, the file or the memory as the system sees it) but we can leave that for later.

Jorpho

  • Hero Member
  • *****
  • Posts: 5006
  • The cat screams with the voice of a man.
    • View Profile
Re: How do I go about translating a famicom disk rom?
« Reply #2 on: April 27, 2021, 10:56:28 am »
The very first thing you do before you even open up the ROM in a hex editor is check whether anyone has done anything like this before.
https://www.romhacking.net/forum/index.php?topic=28930.0
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!