Nakayama Miho's Tokimeki High School (Famicom Disk System)

Started by filler, March 29, 2017, 06:27:25 PM

Previous topic - Next topic

FCandChill

#40
I haven't encountered any documentation on a directory that references FDS files... Thanks anyway, kingmike!

A new version of the utility was pushed to GitHub...



Read the readme for more info.

filler

Looks good! I just had my internet die in the middle of the 7GB Visual Studio download, so it may be a while before I can check this out.

EDIT:

I managed to download Visual Studio. Having some trouble compiling.

I pick make project from existing code -> windows app -> but it says:

The reference assemblies for framework ".NETFramework,Version=v4.0,Profile=Client" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

Seems like this would be as simple as a download, but I don't see anything for .NET Framework 4.0. It's all 4.5 and over.

FCandChill

You'll have to...

1) Make a new solution
2) Recreate the projects
3) Add the class files from my GitHub to your projects through the your OS's GUI
4) Make Visual Studio recognize the files exist by. You do this through the solution explorer by pressing the icon with the sloppily stacked papers. Then you right click each outlined file and select an option to include the files in the project.

Whew...

May 11, 2017, 10:55:53 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

I may have found two files referencing files in the game. On both sides, there's a file called "LS DATA" in ASCII. Considering LS is a UNIX command for file viewing (predates the game by a decade), it's a reasonable guess...

May 12, 2017, 04:40:22 AM - (Auto Merged - Double Posts are not allowed before 7 days.)

Updated the code again. Has a new comparison feature. Keep out the bank 2 text as well for something amusing...

Spinner 8

I took another look at the text banks and the pointers. :) Here's everything I have (for now).

bank1: 91AD-93F2
bank1 pointer: ROM+28B9
bank2 pointer table 917B-91AC (25 strings)

bank2: A3D2-A62E
bank2 pointer: ROM+1B28
bank2 pointer table A3AA-A3D1 (20 strings)

bank4: 10F86-1234C
bank4 pointer: ROM-4E27
bank4 pointer table 10EDE-10F85 (84 strings)

bank5: 14263-15192
bank5 pointer: ROM-7BD5
bank5 pointer table 141E3-14262 (64 strings)

bank6: 167B4-174C2
bank6 pointer: ROM-A6D6
bank6 pointer table 16704-167B3 (88 strings)

bank7: 1828C-18815
bank7 pointer: ROM-C9B4
bank7 pointer table 18252-1828B (29 strings)

bank8: 1A02A-1AB3F
bank8 pointer: ROM-DD14
bank8 pointer table 19FB2-1A029 (60 strings)


Note that bank 3 isn't listed, and this all assumes a ROM without header.

FCandChill

Thank you for that information, Spinner8. All that info is good on my end except for the last bank ... bank #8. Could you double check that one? (FDS headers are pointless ... all the information contained in it can be figured through the disk dump size...)


Good news... I added code to limit the script size when inserting!
Bad news... I didn't realize how bad the dictionary compression is... Dumping and reinserting gives an error of the script being 26 bytes too large...

Spinner 8

Quote from: FCandChill on May 13, 2017, 02:28:11 AM
Thank you for that information, Spinner8. All that info is good on my end except for the last bank ... bank #8. Could you double check that one? (FDS headers are pointless ... all the information contained in it can be figured through the disk dump size...)

Hmm, I just double-checked everything and it still looks good to me. I could be missing something though.

FCandChill

Quote from: Spinner 8 on May 13, 2017, 12:52:28 PM
Hmm, I just double-checked everything and it still looks good to me. I could be missing something though.
I could be missing something too... Filler, how are you doing with the utility? I made a new update.

filler

Quote from: FCandChill on May 14, 2017, 11:04:59 PM
I could be missing something too... Filler, how are you doing with the utility? I made a new update.
Not so good. :( I tried making a project and adding the files like you said, but I'm still getting some errors. Would it help if you share the Visual Studio project files with me directly?

FCandChill

Quote from: filler on May 15, 2017, 10:44:31 AM
Not so good. :( I tried making a project and adding the files like you said, but I'm still getting some errors. Would it help if you share the Visual Studio project files with me directly?

The source of the issue probably... Go to "Project > Add reference". This will allow you to have projects reference each other.

filler

Quote from: FCandChill on May 15, 2017, 01:11:59 PM
The source of the issue probably... Go to "Project > Add reference". This will allow you to have projects reference each other.
This is what I have now:


If I go to add reference I get this dialog:



The only things that seem to be selectable are these extensions.

FCandChill

There's your issue... You created one project for the solution and placed folders inside of it. Miho, Diskinfo, et al should get separate projects. Right click the "Solution App1" ... and created a new "Windows Form Application". Then for the other projects, created a new class library. After that, place the files in the respective projects.

filler

Quote from: FCandChill on May 15, 2017, 04:47:16 PM
There's your issue... You created one project for the solution and placed folders inside of it. Miho, Diskinfo, et al should get separate projects. Right click the "Solution App1" ... and created a new "Windows Form Application". Then for the other projects, created a new class library. After that, place the files in the respective projects.
Still trying... :banghead:

So I made a new project that's a "Windows Form App" and called it "MihoUtil". This made the solution, and first project.



Then I made a new project, "AddressStuff"



And copied the contents of the remote "AddressStuff" inside, and did like you said before and added the files to the project.



I did this for all folders. Now I seem to be able to build without errors, but I get a blank form. Thoughts?


FCandChill

Right click the Miho project ... and select the option to set it up as the start project.

filler

Quote from: FCandChill on May 15, 2017, 10:24:29 PM
Right click the Miho project ... and select the option to set it up as the start project.
I get these messages.



FCandChill

###
#54
Comment removed because reasons...

filler

This is basically telling me it can't find classes that exist in the sub projects (AddressStuff, etc.) despite these projects having been "added". There's something funny here, and I'm running out of patience for this.

I advocate abandoning the approach of me having a copy of the code I can compile. Is there some other way we can test the dumper/inserter and move forward with this?

EDIT:

Yay :woot!: Hurrah  :woot!:

FCandChill: Thanks for getting me a version of the dumper/inserter. Below is the first bit of my test insertion.



I messed up on the English table file in that I wasn't very diligent. I still need to switch a lot of the Japanese characters over to English and such. Example:

"Hello。 This is Miho Nakayama。Hello。 This is Miho Nakayama。Are you enjoying "Miho Nakayama'sTokimeki High School"?Huh? Not yet? The love story can'tbegin without you! Hurry and start the gameokay。 I'll be waiting。This has been a notice from Miho。    Press the A buttonFor starters、 a note about disk fax。We're accepting entries from Dec。 19th、to Feb。 29th。"

Am I able to edit that table file and use it right away, or will that need to be sent back to you? Also I tried \# as the line character, but it said it was not a character that was in the table.

If you'd rather do this via PM, just PM me the response.

FCandChill

"\#" is a special case character... When exporting ... the character is replaced with a linebreak. For importing don't use the character and use your OS's linebreak.

Spinner 8

filler asked me to take a look at the dictionary table and pointers.

The values are located from #60 through #9E in the TBL (#9F is a special case for the player's name), and the table is from 7B38 through 7C82 in the ROM. The TBL value at #60 labeled "[STARTDIALOG]" is simply a colon, line break, and a quotation mark, so you can change that to something else if you like (for instance you can remove the line break if you're concerned about a lack of space on-screen).

There are actually no pointers for the dictionary values - the game will simply start at 7B38 (300 in RAM) and "count" each end break (#FF), until it reaches the right number. I hope that makes sense, but essentially, as long as the dictionary values are all sequential, they'll work fine without needing pointers - with one exception.

The dictionary values are added to RAM at 300-44A. 44B-44F are five bytes reserved for the player's name (four characters plus the #FF end break), appended to the end of the dictionary values. I'm not sure if the dictionary table can be expanded (I imagine that would take a lot more testing to find out), but the name pointer is stored at 4E4 in the ROM if you want to move it elsewhere. Just make sure it's at the very end of the dictionary table.

Let me know if I can help with anything else.

(edited for clarity)

FCandChill

Thanks Spinner 8! I think I'll go ahead and add you to the credits part of the program ... because you deserve it! The dictionary can now be modified but that special case $9F is tripping me up... Where is the string located in a non-headered disk image and where is the pointer? The pointer location you gave me is where a file name is...

Spinner 8

Quote from: FCandChill on May 18, 2017, 05:04:07 PM
The dictionary can now be modified but that special case $9F is tripping me up... Where is the string located in a non-headered disk image and where is the pointer? The pointer location you gave me is where a file name is...

Well it's the player's name, which they enter themselves when they start a new game, so it's not exactly a string you can locate. Once the name is entered after starting a new game, it gets stored at $44B in RAM for dictionary purposes... and probably elsewhere too, I mean it's a disk-based game so I'm sure it's saved to a more permanent location, but that doesn't really matter much in terms of the dictionary compression itself.

Again, if you want to expand (or shrink) the dictionary table, you'll need to move the location of that player name in RAM (not ROM) to wherever the end of the table is. The pointer for that name is at $4E4 in the ROM (not RAM). :)

EDIT: I just realized there may be a separate pointer when loading a game (as opposed to starting a new game). I kind of doubt it, but the coding in this game is kind of weird, so who knows. I'll take a closer look later at how the name is saved and loaded.

ANOTHER EDIT: I pulled up the game in a hex editor just now, and I see what you mean about the pointer being where a file name is... I don't think it's a file name ($141-$3C12 is all one file named "OPEN"), but immediately after the pointer is the word "DISK" in ASCII. Still, I'm pretty sure that that's the correct pointer, so I'll double-check and confirm it later on today.