Author Topic: Menu module data documented. (Read 5854 times)

halkun · « **on:** 2004-07-19 01:52:20 »

Yes, the great menu. I've documented it and also did some neophyte field scripting today to figure out the MENU() arguments.(YAY!)

It's all in Gears.

If anyone has a PSX, and you feel like decrypting the /menu/*.mnu files, go right ahead. I only know how to call the callable ones. I'm wondering if the MNU files use a scripting language as well? I doubt it as the menu system is internal to the PC version. (No .MNU files)

If I didn't know better, I'd say that Itemmenu.mnu and savemenu.mnu have some kind of texture in them

Not only that. I'm getting so good at eyballing raw hex, I think savemenu.mnu has that sword that's displayed in the begin menu.

(It makes sense, as it uses the same scroll-o-matic pick your save game)

I need to go to bed. Someone mind picking up where I left off? Could you also look it over and tell me what you think?

I also updated the scene.bin data too. PIck up the new gears at the www button.

::EDIT::

Yup, the .mnu files hold tims, and I was right, it was the sword.

The data also seems to align on every four bytes. Intresting...

Cyberman · « **Reply #1 on:** 2004-07-19 15:12:00 »

Halkun that's consistant with everything thus far in the Playstation version of FF7, 32bit word alignment in files. That might mean it has a leading index table pointing to the structure of it.

Too bad the DAT files aren't like that (sigh).

Cyb

EmperorSteele · « **Reply #2 on:** 2004-07-19 22:44:45 »

I dont suppose, now that you have a grasp of how the menu works, that there's any way to edit the menu so that theres a "load" feature? It's the one thing about ff7 thats always irked me, cuz i have a tendancy to laod up the wrong save when i wanan do somethin -_-

halkun · « **Reply #3 on:** 2004-07-19 23:00:12 »

Actually, "Load" is really "Save" called from "begin"

I tried to call the "load screen" using the MENU command, but didn't see anything obvious. I was able to get the save screen, maybe the load one is a sub function?

Cyberman · « **Reply #4 on:** 2004-07-20 15:31:36 »

Quote from: halkun

Actually, "Load" is really "Save" called from "begin"

I tried to call the "load screen" using the MENU command, but didn't see anything obvious. I was able to get the save screen, maybe the load one is a sub function?

Ok.. here is possibly a way to figure it out.
On boot up, what script starts things? It has to be a script, because FF7 is completely scripted. there must be a start script for the game, from there you have the INTRO and then the initial New Game/Load Game menu. I'm sure the New Game runs the start up script for the game. And Continue runs a script to check the cards for save states. That's how I see it at least.

Cyb

halkun · « **Reply #5 on:** 2004-07-21 11:34:41 »

Ok did a little hacking this morning before work.

It turns out I was right, when FF7 banks in a module, they are pre-initalized so all it does is put a mirror of what's on the disk into memory.

I've decided to take a stab at defining the .MNU file format. I did my trick of savestate editing.

In the debug room I amde a save state with the menu open to "status" (That one exibits a lot of cool functions can controls)

After gunzipping the save state I find that STATMENU.MNU is loaded in memory at location 0x1d01ba-0x1d1f9d. You can tweak the file in memory using the save state and then load the save state to see what you changed.

At the tail end of STATMENU.MNU is the text for the menu. I changed "Strength" to "Suck" and loaded the save state. It was updated in the menu as soon as the save state was loaded so it looks like .MNU files are read every cycle in memory.

If you leave the status menu and return, STATMENU.MNU is realoaded from the disk and you loose all your changes. This is a good way to "clean" your save states so you can corrupt something else.

Cyberman · « **Reply #6 on:** 2004-07-21 17:06:27 »

Quote from: halkun

It turns out I was right, when FF7 banks in a module, they are pre-initalized so all it does is put a mirror of what's on the disk into memory.

So basically it just copies te menu data into memory each time you change the menu states?

Quote from: halkun

In the debug room I amde a save state with the menu open to "status" (That one exibits a lot of cool functions can controls)

After gunzipping the save state I find that STATMENU.MNU is loaded in memory at location 0x1d01ba-0x1d1f9d. You can tweak the file in memory using the save state and then load the save state to see what you changed.

At the tail end of STATMENU.MNU is the text for the menu. I changed "Strength" to "Suck" and loaded the save state. It was updated in the menu as soon as the save state was loaded so it looks like .MNU files are read every cycle in memory.

I'm not sure what you mean, you mean each time you change the state in the menu? They likely do that because sometimes the PSX memory gets corrupted inexplicably (idiot user is the translation for this

). Which means to keep things in a known state you should fetech a known good copy (IE when a state changes read the data from disk immedately!)

Quote from: halkun

If you leave the status menu and return, STATMENU.MNU is realoaded from the disk and you loose all your changes. This is a good way to "clean" your save states so you can corrupt something else.

The absolute irony of that statement is not lost on this user LOL, should you decide to have a name for a hacking group, I suggest 'Lords of Corruption'

It just fits

Cyb

halkun · « **Reply #7 on:** 2004-07-21 17:27:51 »

Quote from: Cyberman

So basically it just copies te menu data into memory each time you change the menu states?

When you move the finger down the left hand side and select "status', it dumps out the current menu and loads the new menu from the disk. When you exit status, it dumps out the status menu and loads the party one. The variable data is kept elswhere.

halkun · « **Reply #8 on:** 2004-07-23 23:10:04 »

It's been two days, time for an update...

I fear that the menu module is not scripted, but actually consists of bona-fide R3000A machine code. This solves a lot of questions like the fact the PC menu is internal with only the graphic depednecies placed in the menu LGP file. It also answers why the current loaded menu module is "ran" every cycle. (i.e. placed in the actual program loop)

I don't have a mips dumper ot I could tell if the code is real machine code or not. I know that some MNU files also have embedded TIM files at the end and refrences to devices at the beginning. (Save has bu00: and bu01: for the memory cards and x:/ refrences for the CD-ROM in the party menus)
I'm gong to just document the textures and call that section finished for now.

Then I'll move on to expanding some of the pre-history I think.

Cyberman · « **Reply #9 on:** 2004-07-25 18:30:49 »

Quote from: halkun

It's been two days, time for an update...

I fear that the menu module is not scripted, but actually consists of bona-fide R3000A machine code. This solves a lot of questions like the fact the PC menu is internal with only the graphic depednecies placed in the menu LGP file. It also answers why the current loaded menu module is "ran" every cycle. (i.e. placed in the actual program loop)

I don't have a mips dumper ot I could tell if the code is real machine code or not. I know that some MNU files also have embedded TIM files at the end and refrences to devices at the beginning. (Save has bu00: and bu01: for the memory cards and x:/ refrences for the CD-ROM in the party menus)
I'm gong to just document the textures and call that section finished for now.

Then I'll move on to expanding some of the pre-history I think.

Hmmm I guess that explains things I wonder if it calls kernal functions directly from itself?
It makes sense that it is code though for the LOAD and SAVE functions, since those are machine dependant in this case.

Cyb

halkun · « **Reply #10 on:** 2004-07-25 23:50:52 »

On a slightly realted note. I've updated Gears (www button). I wanted to finish the KERNEL section after MENU, but becuase I had the Kernel.bin/window.bin breakthrough, kenrel became much more expansive than I had time to write.

I'm burnt out again, but at least MENU is done.

I was also hoping to do some text reformatting, but that sorta fizzled out as well...

Anyone wanna take kernel.bin part and tell me what's inside it? Thanks.