[Pennywise]

I'll be keeping the game in mind for future projects. I don't want to work on too many FDS translations at once considering how much of a pain they are to hack. It'll probably be down to Mr. Gold or this game for my next FDS project, but I did take the liberty of breaking down all the files and getting an overview of how the PRG-RAM is used and it's pretty much full. However, since the game already uses compression, it might be possible implement a more powerful method instead to get a decent sized script back in.

[filler]

I appreciate that. Has anyone translated the Mr. Gold script yet? If not, I might be up for some quid pro quo. I'd never heard of it before. That intro Engrish is pretty epic.

[Pennywise]

Nah, I haven't gotten that far yet. It's just a casual interest mostly because of that intro. It might come down to which one would be less work.

[KingMike]

I only heard of Mr. Gold when Tomato was streaming him reading some of his retro Japanese game magazines and apparently Mr. Gold was at one point like the #2 most-written game by Disk Writers or something like that. (I heard SMB2 was the #1 overall over the lifetime of Disk Writers but I'm not sure at that time.)

[FCandChill]

Who would like to help me insert this script?

I can write the code to insert the script. I just need the proper documentation (e.g. pointers, table, etc.) Just keep the conversation on the forum ... instead of PM.

I did find a library for dictionary compression ... should help http://forums.nesdev.com/viewtopic.php?t=5677

[filler]

Miho Nakayama's Tokimeki High School Script Package

This has table files and notes on offsets. That's all the info I have.

That compression tool loks cool!

[FCandChill]

Comment removed because reasons...

[filler]

I don't know how to find dialog pointers unfortunately. 

[KingMike]

Can you find the dialogue in RAM (using the hex editor in FCEUX to search RAM while running)?
Or using a program, such one I wrote (I think I called it FDS Builder) to split the FDS image into files, the pointer can be found by finding the offset within the split file and adding it to the file's RAM offset (which would be listed in a contents file generated by the program).

[FCandChill]

Comment removed because reasons...

[filler]

Can you find the dialogue in RAM (using the hex editor in FCEUX to search RAM while running)?
Or using a program, such one I wrote (I think I called it FDS Builder) to split the FDS image into files, the pointer can be found by finding the offset within the split file and adding it to the file's RAM offset (which would be listed in a contents file generated by the program).

So here's the first bit of dialog in RAM. Highlighted is "ここは". Does this help? What do I do next?

Nice...

Assuming you get those pointers, how do you want this program done? Also, it would be nice to get pointers for the DTE table, so it can be modified. Here's options to consider...

• ☐Terminal or ☐GUI
• ☐Import and export script only ☐Edit one by one. ☐Both
• For the edit one by one option with a GUI... do you want to see a comparison between the original and the Japanese text while editing the script? ☐Yes ☐No
• Use DTE compression ☐Yes ☐No
• Be able to edit DTE table ...proper documentation must be provided... ☐yes ☐No

...submit a copy. Fill it out with the ☑ character, a checked checkbox.

I guess if we're going to make a fancy dumper/inserter GUI would be nice. I don't think one by one is necessary. Just dump the whole script and reinsert. Not sure why we'd want to toggle DTE off in this case? I think that's the important part. Would this use the DTE utility you linked to? Is there any reason to edit the DTE as opposed to building it automatically?

The cool thing about this, aside from getting the English script in there, would be if this helps folks make other language versions.

[Spinner 8]

Yeah, I checked it out. Does this game not use pointers for the dialogue? Some games generate pointers on the fly. If not, offsets will not be enough to create a tool for you...

I was taking a quick look at this game last week. The first two text banks (91AD-93F2 and A3D2-A62E) have the pointer tables just ahead of them. Bank 1's pointers start at 917B, bank 2's start at A3AA. (These addresses assume no header.)

Hope this helps a bit

EDIT: I forgot to mention the pointer offset! Bank 1 pointers are the ROM address + 28B9, and bank 2 pointers are the ROM address + 1B28. I don't think bank 3 has a pointer, since it's just a single long message. I didn't look at the other text banks.

[FCandChill]

Comment removed because reasons...

[filler]

The table file should be sjis. I can double check.

[FCandChill]

The table file should be sjis. I can double check.

Alright thanks ... I got it to work now!
May 08, 2017, 09:13:59 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Just a demo

[KingMike]

The RAM address in that screenshot should be C088. So, C088 should be the pointer value.

You can't easily convert from offset in a .FDS file because an FDS game is an image with several files inside. Files get loaded to RAM (which is where the games are run from), and so the pointer depends on WHERE in RAM that data gets loaded to (that RAM address is in the file header, if you can find the header in the .FDS).
I'm not 100% but it SEEMS that files in an FDS image are stored sequentially and they seem to always have filenames (8 characters) in ASCII (at least the games I have looked at). If I recall, the header format was: a 0x03 flag, 8-character file name, file size and RAM offset (2 bytes each, maybe not that order), then 1 byte indicating destination RAM (PRG-RAM, CHR-RAM or PPU), then a 0x04 flag then the file data.
Without using a tool to rip a file list from the FDS, you'd have to scan through the file to look for ASCII text (for the filenames) and do math using the file size data to find where the files are. Or use the FCEUX hex editor to find the RAM offsets to find pointer values and then do a hex search to find those.

[FCandChill]

Thanks, kingmike. Everything is loaded into memory and then read for the FDS ... so it makes sense that RAM addresses would be used as pointers. The guide of NesDev is helpful. So I can either hardcode where I read the RAM offsets or not... In theory, I could map out where the files are in the ROM and read where the RAM addresses are stored instead of hardcoding the location. Detailed documentation on how to do this would be nice ... or a code library I could use.
May 09, 2017, 08:34:05 pm - (Auto Merged - Double Posts are not allowed before 7 days.)Current code https://github.com/romhAndAcking/Miho/

[filler]

Awesome! I'll check this out tonight.

[FCandChill]

I actually finished stealing doing the code for compression. Now to modify the pointers. Is there a byte in the file specifying how many pointers there are? I just hardcoded the values...

Also ... the game don't leave any space in the files ... but there's plenty of space on the disk. You may want to consider moving files around and expanding them ... if the game even allows you to...

[KingMike]

I think files might only be stored sequentially (there doesn't seem to be any kind of TOC, if I'm guessing right what a TOC is in CD-based games (it says what sectors files are stored at on the disc?), which I haven't hacked). Files could be expanded (if you separate and rebuild the FDS disk contents) but depending on the game could overwrite other data if the following RAM (after the end of where the file is loaded) is used for other files or other data.
As an example, in Deep Dungeon 1 and 2, I was able to expand the individual level data a little bit because I was lucky that the particular games reserved an extra 0x100 bytes in RAM (than what the largest level file actually used) between where the other data would be loaded in RAM.
(well, some of that RAM space was used to store dialogue window text as it was being rendered but a few minor ASM hacks were all that I needed to move it around a bit in RAM to get the little extra space I needed in that situation).