About the MMC3 Mapper and Address Conversions

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
arcangeldemerida
Posts: 21
Joined: Wed Jun 22, 2022 7:00 am

About the MMC3 Mapper and Address Conversions

Post by arcangeldemerida »

I am working with a disassembly of a game that works with that mapper (MMC3).

I need more detailed information about that Mapper and its conversion from PC addresses (from the ROM) to NES addresses (CPU).

In a ROMHacking.net post, I found that PC to NES address conversions depend on the Mapper.
https://www.romhacking.net/forum/index. ... ic=27045.0
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: About the MMC3 Mapper and Address Conversions

Post by Ben Boldt »

There isn’t a 1 size fits all conversion. It is confusing that you use the term PC, because that often means “program counter”. You are wondering the conversion from ROM address to CPU address.

First of all, there is usually a 16-byte “iNES” header added to the ROM file. So, ROM addresses are always +16 (or + hex 0x10) because of this.

Next, the CPU ROM addresses are always in the range 0x8000 through 0xFFFF. That is only 32 kilobytes. So, mappers are designed to take different chunks of the ROM file and insert them into this 32 kilobyte window for the NES’s CPU to see, so that more than 32k can be used. Depending on the mapper and how it is configured, there can be any number of smaller windows in this region that can be switched with different chunks of ROM all independently. So unfortunately there isn’t a really simple straightforward conversion from ROM to CPU addresses.

Depending what you are doing, there are simple ways to deal with it though. For example, if you know 5 or 6 bytes of the disassembly, you can open the ROM file in a hex editor and search for those bytes. It doesn’t take many bytes to narrow it down to 1 match. And then if you see that the ROM address, -0x10, ends the same way as your disassembly address, then you especially know that you found it.

In an emulator with debugger, you will often find an option to show CPU address vs ROM address. So if you can find the right spot with a debugger, it will tell you everything.

I am sure there are other tricks too. Just keep hacking around with it and you will find more things that work for you.
arcangeldemerida
Posts: 21
Joined: Wed Jun 22, 2022 7:00 am

Re: About the MMC3 Mapper and Address Conversions

Post by arcangeldemerida »

Ben Boldt wrote: Sun Sep 18, 2022 9:39 am In an emulator with debugger, you will often find an option to show CPU address vs ROM address. So if you can find the right spot with a debugger, it will tell you everything.
Ok, is there any way to do that in the Mesen emulator?
I need to know the address to reassemble the game.

The game has 32 banks of 8kb (16x16).
User avatar
Ben Boldt
Posts: 1149
Joined: Tue Mar 22, 2016 8:27 pm
Location: Minnesota, USA

Re: About the MMC3 Mapper and Address Conversions

Post by Ben Boldt »

Honestly I haven’t used Mesen much. It looks like the top row of the call stack shows the ROM file address. Fceux has a checkbox, that is what I was thinking of. I don’t see anything like that in Mesen.

Edit:
Oh I found it. It is code -> prg address display. That shows the ROM address on every line of the debugger.
unregistered
Posts: 1318
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: About the MMC3 Mapper and Address Conversions

Post by unregistered »

If you’re in Mesen’s debugger and choose Code>PRG Address Display>Inline Compact Display, then that will show the addresses on the left side of the debugger window as:

Code: Select all

CE01 [3C]
and that just means the ROM Address is supposed to be 3CE01 for that line.

It’s always like that… just truncate the left most hex digit from the CPU address and then replace that empty space with the information inside the [ ].


Also, if you open up your ROM’s .cdl file in a hex editor, then you can visually see the entire byte for byte Mesen Debugger formatting. All of the PRG Addresses, calculated above in this post, are the addresses to be used for your .cdl file. (i.e. don’t search for CPU address CE01, when you should search for ROM address 3CE01. I’ve made that mistake MANY times… so it is possible to mess up your .cdl file in that manner, if you edit the wrong .cdl byte.)

The set 7th bit instructs MESEN debugger that a function/procedure starts at that byte.

The set 0th bit instructs MESEN debugger that that code has been run before.

The set 1st bit instructs MESEN that that byte is part of a data section. Data sections are represented visually different in the debugger.


EDIT: fixed many incorrect statements and added more info

FINAL-EDIT: .cdl files can be found in your Mesen\Debugger folder. And, to see changes from .cdl file edits, it is necessary to, in Mesen’s debugger, access Tools>”Code/Data Logger”>”Load CDL file…”, IF: File>Workspace>”Auto-Load CDL files” ISN’T checked.

Though, I’m unsure if MESEN only Auto-Loads a .cdl file when a ROM/game is loaded.
Post Reply