NES equivalent for VBA's disassembler?

[Chaos Rush]

So for GBA games, VBA has an ASM decompiler that lets you type in a ROM offset and attempts to interpret it as ASM code. This makes hacking stuff like menus a lot easier, as you could just find the pointer to a text string shown in a menu, and then use VBA's decompiler to try and find the ASM code that references that pointer. I am wondering if there is an NES emulator with a similar function. I would like to alter the size of the menus in Final Fantasy II, and I am also wondering how Grond did it for Final Fantasy I. I think Fceux has a decompiler but the way it displays NES offsets are confusing to me, and I couldn't find any info on how to decompile ASM code at a specific offset.

[Disch]

You're probably not going to find a direct equivalent.

FCEUX's addresses are confusing because NES addressing is confusing.  To really understand them, you just have to understand some NES memory basics.  To make matters even more complicated, how memory works can vary from game to game.

Here's what you need to know for FF2:

NES ROMs start with a 0x10 byte header.
After that there are a series of "banks" of PRG-ROM, each bank being 0x4000 bytes (16K) in size.  So the ROM looks like this:


0x00000 - 0x0000F = Header
0x00010 - 0x0400F = PRG bank 0
0x04010 - 0x0800F = PRG bank 1
0x08010 - 0x0C00F = PRG bank 2
0x0C010 - 0x1000F = PRG bank 3
0x10010 - 0x1400F = PRG bank 4
0x14010 - 0x1800F = PRG bank 5
...
0x3C010 - 0x4000F = PRG bank F


FF2 has 2 "slots" in memory:

$8000-BFFF = can have any one bank swapped in at any time
$C000-FFFF = always has bank F swapped in.


This means that when you are looking at 'NES Memory' in FCEUX, the $C000-FFFF range will always match offset 0x3C010-0x4000F in the ROM.

However, the $8000-BFFF range in NES Memory will often change between a different 16K bank of ROM as the game swaps in difference blocks as they are needed.  In FCEUX, if you are in 'NES Memory' view in the hex editor, you can right-click on a byte in that range and say "Go here in ROM file" and it'll switch to ROM view telling you the exact file offset.



----------------

All of that said... what I usuaully do is create a full disassembly of the game (just using a naive disassembler, like 6502d).  You'll get a lot of garbage, but it's good enough for a reference.  Then use that to jot down notes and read/follow code while using FCEUX to step through it.

[Chaos Rush]

Thank you, that is really helpful. Am I right in assuming that NES pointers can only reference data within the ROM bank it's located in?

[Disch]

Thank you, that is really helpful. Am I right in assuming that NES pointers can only reference data within the ROM bank it's located in?

Kinda sorta.

Yes - this is how games usually work.
But no - they do not have to work this way.

In FF2 it's a pretty safe bet that pointers will not reference anything outside their own bank.

[MeganGrass]

So for GBA games, VBA has an ASM decompiler that lets you type in a ROM offset and attempts to interpret it as ASM code.

This program will let you disassemble a NES rom from any offset. The output disassembly can be recompiled, etc.

Like Disch said, you need to use FCEUX to obtain the ROM file offsets then feed it to the app. It also expects a program counter, for example:

$C000 - Program counter
0x03C010 - ROM File Offset

Example Commandline:
x6502 label address org 0xC000 start 0x03C010 finish 0x040010 rom ".\Mega Man 2.nes" out ".\DisAsm.s"

[KingMike]

Though I recall FF1's windows using hard-coded size/location parameters.
I don't know if FF2 is similar. I suspect out of battle menus might be possible to expand.

However, in-battle menus might be a bit more restricted.
From looking at the Name Table Viewer in FCEUX, it looks like FF2 is using some kind of CPU trickery where the main battle screen is a static tilemap, but the menu part of the screen is actually scrolled horizontally (without affecting the top part of the screen). Like you notice FF2 has basically three windows: the enemy name window, the main stats window, and the command window. All three are actually loaded into the VRAM (across the NES' 2-screen wide tilemap) but the enemy and command windows are hidden at appropriate times using that partial-screen scroll.
FF1 looks like it's erasing the old windows before redrawing new ones (that is, something different).

[AWJ]

Though I recall FF1's windows using hard-coded size/location parameters.
I don't know if FF2 is similar. I suspect out of battle menus might be possible to expand.

However, in-battle menus might be a bit more restricted.
From looking at the Name Table Viewer in FCEUX, it looks like FF2 is using some kind of CPU trickery where the main battle screen is a static tilemap, but the menu part of the screen is actually scrolled horizontally (without affecting the top part of the screen). Like you notice FF2 has basically three windows: the enemy name window, the main stats window, and the command window. All three are actually loaded into the VRAM (across the NES' 2-screen wide tilemap) but the enemy and command windows are hidden at appropriate times using that partial-screen scroll.
FF1 looks like it's erasing the old windows before redrawing new ones (that is, something different).

Final Fantasy 2 uses a polled raster split (spinning until sprite 0 hit) to split the battle screen into upper and lower halves. The monsters and backdrop use one side of the pattern table and the text font uses the other side, and the upper and lower halves can (horizontally) scroll independently. It shouldn't pose an obstacle to changing the size of the individual windows--you're not trying to change the vertical position of anything, after all.

[Chaos Rush]

I'm not just trying to change the size of the windows, I would also like to reposition some text. Unfortunately I've been quite busy these past few days so I haven't had time to actually apply the info you guys have given me.