What do I need to know to convert a modified MMC3 to MMC3?

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

User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

What do I need to know to convert a modified MMC3 to MMC3?

Post by double_jumper »

I'm really newbie to this whole scene, and to be honest I just want to play Dragon Buster on a platform without support for its mapper (95). But I don't mind having to learn a bunch of stuff to do that, just needing some guidance.
Or would it be less work to just try and patch the emulator?
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: What do I need to know to convert a modified MMC3 to MMC

Post by koitsu »

What is "the emulator"?
User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by double_jumper »

That'd be any for the 3DS, where I'm trying to play it. Tried a couple, but they didn't seem to work for this game, or don't have working download links, or they deleted their github page.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by lidnariq »

Mapper 95 requires one-screen mirroring, which the MMC3 (mapper 4) doesn't support.

There are other mapper hacks that could be made to work (e.g. m118, m158, m207), but support for them in emulators isn't tremendously more likely than m95. (That list is in descending likelihood of being supported)
User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by double_jumper »

lidnariq wrote:There are other mapper hacks that could be made to work (e.g. m118, m158, m207), but support for them in emulators isn't tremendously more likely than m95.
Well actually, m118 seems to be supported by one! How would I go on doing that?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by lidnariq »

Well, what I'd do is:
Load the game in a debugging emulator (FCEUX for windows, Nintendulator, Mesen)
Set a breakpoint on writes to $8000-$9FFF
Discover that the game seems to always keep a shadow copy of the CHR banking registers in RAM
Disable old breakpoint, set a new breakpoint on writes to that shadow copy
Discover that the game seems to keep 6-byte arrays in ROM corresponding to the desired PPU memory layout
Change the corresponding tables in ROM, change the mapper # in the header, and see if it works correctly
User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by double_jumper »

lidnariq wrote:Well, what I'd do is:
Load the game in a debugging emulator (FCEUX for windows, Nintendulator, Mesen)
Set a breakpoint on writes to $8000-$9FFF
Discover that the game seems to always keep a shadow copy of the CHR banking registers in RAM
Disable old breakpoint, set a new breakpoint on writes to that shadow copy
Discover that the game seems to keep 6-byte arrays in ROM corresponding to the desired PPU memory layout
Change the corresponding tables in ROM, change the mapper # in the header, and see if it works correctly
I probably should've been more clear, I only know the basic idea of mappers and some MIPS assembly I've seen in college. I was hoping I could figure some things out with the debugger (using FCEUX), but I'm not sure of how to identify most of those things.
What I've got is that the game copies these registers from the cartridge, so I gotta find this copy, get this PPU memory layout from those arrays, and use these values to edit the ROM.
So... I don't know how to find this shadow copy. Or identify CHR banking registers. Or 6-byte arrays. Or those tables in the ROM. :?
You've helped a lot, I just don't know what I'm looking for looks like.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by lidnariq »

So ... uh, Debug / Debugger ... pops up this window
and in the upper right corner you can add a new breakpoint by clicking on the "add" button

Start off with the documentation at nesdevwiki:iNES Mapper 095 which points you at nesdevwiki: iNES Mapper 206 ... ok, so you need to set a breakpoint on writes to $8000-9FFF because that's where the N108 listens.

The N108 and MMC3 are kinda inconvenient to debug because you need to know both what value it wrote to $8000 before any write to $8001. But fortunately this game always puts them immediately adjacent when you look in the disassembly listing.

There's a writeup here about reverse-engineering the compression format used by a random puzzle game; it involves a lot of the same background skills.

Let me know if you want more guidance.
User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by double_jumper »

Actually i had figured out how to set those breakpoints haha... It's just the "now what?".
What am I looking for on those breakpoints that points me to the shadow copy?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by lidnariq »

At some point you'll find the following code:

Code: Select all

  ldx #5
loop:
  stx $8000
  lda $383,x
  and #$1f
  sta $8001
  dex
  bpl loop
  rts
If you reason your way through it, you'll see that it copies the five bytes from [$383+x] to the N108 register #x

It also specifically masks off the upper three bits of each write, which when you combine it with the write-up about how mapper 95 works, means that it's always forcing the nametables to "1-screen A".

And there's another loop that looks similar, but doesn't mask off the upper three bits.

So this is where I did the same thing to find how the values got in to RAM at $383 through $388
User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by double_jumper »

Alright, I've found an array that it copies from just as the game boots ($85A2-$85A7), another when you start the game ($C4CD-$C4D2), and another when you enter a level ($C4C7-C4CC). I see that the first is in that first interval and that the others are adjacent. Does those values at $85A2-$85A7 (14 16 00 01 02 03) have anything to do with the pinout? Probably just grasping at straws now...
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: What do I need to know to convert a modified MMC3 to MMC

Post by tepples »

For Namco 108 and MMC3, the values are offsets from the beginning of CHR ROM in units of 1024 ($400) bytes. The first two cover 2 KiB regions at $0000-$07FF and $0800-$0FFF; the others cover 1 KiB regions at $1000-$13FF, ..., $1C00-$1FFF. (MMC3 can invert the sense of bit 12 such that the banks instead start at $1000, $1800, $0000, $0400, $0800, and $0C00.) So 14 16 00 01 02 03 means switch CHR ROM $05000-$05FFF into PPU $0000 and $00000-$00FFF into PPU $1000.

Is a value greater than $1F ever written to $8001? If not, then you could probably just take the existing ROM and run it on TLSROM (mapper 118). If so, you'll need to map values $20-$3F to $80-$9F, and it'll run on TLSROM.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by lidnariq »

So, those six values are the values that are written to the N108's first six banking registers. (While "real" computers' MMUs have 4 KiB or 2 MiB banks and only one address space, the NES MMCs have two address spaces and often a random mix of different sizes of banks)

N108 and MMC3 both use the same PPU banking scheme, allowing control of two 2 KiB windows and four 1 KiB windows. (The MMC3 refines this by allowing the user to swap which comes first)

So if the game ultimately writes $0→[$8000] then $14→[$8001], that means "set the 2 KiB CHR bank at $0000-$07FF to bank #$14 and, in the case of mapper 95, set the nametable in the top half (the $20s bit) to 0"

In contrast, the same write to mapper 118 would mean "set the nametable in the top half (the $80s bit) to 0".

Does this make sense so far?
User avatar
double_jumper
Posts: 8
Joined: Sat Dec 24, 2016 3:50 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by double_jumper »

lidnariq wrote:Does this make sense so far?
I got how it works now, I only don't visualize these $20s and $80s banks. Top half of what? That could probably answer my next question.
tepples wrote:Is a value greater than $1F ever written to $8001? [...] If so, you'll need to map values $20-$3F to $80-$9F, and it'll run on TLSROM.
Yes... And I really tried searching before asking, but how do I map these values?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: What do I need to know to convert a modified MMC3 to MMC

Post by lidnariq »

Before I go too far off ... do you understand what a nametable is? What mirroring is? We have some articles on the wiki which hopefully will help, if not: nesdevwiki:Mirroring and nesdevwiki:PPU nametables.

From an EE point of view:
Mapper 95 connects what would have been CHR A15 instead to "CIRAM" (= nametable) A10. The N108 (& MMC3) drives values from its first six registers depending on the instantaneous state of PPU A10, A11, & A12 (but not A13 — that's why this works!)
So when the PPU is fetching from $0000-$07FF or $2000-$27FF (because it's not connected to A13), it drives the CHR ROM (and also CIRAM A10) according to the contents of register 0.
Similarly, when it's fetching from $0800-$0FFF or $2800-$2FFF, it drives the CHR ROM (and CIRAM A10) according to the contents of register 1.

This means that there are four possible ways that the NES's two nametables can be combined:
[R0] & $20 = 0 and [R1] & $20 = 0 → CIRAM A10 is always 0, regardless of PPU A10, A11
[R0] & $20 = $20 and [R1] & $20 = $20 → CIRAM A10 is always 1, regardless
[R0] & $20 = 0 and [R1] & $20 = $20 → effectively, CIRAM A10 is connected to PPU A11
[R0] & $20 = $20 and [R1] & $20 = 0 → effectively, CIRAM A10 is connected to NOT PPU A11

Mapper 118 is the exact same idea.... it's just that they used the pin that's usually connected to CHR A17 instead to CIRAM A10. So the bit becomes $80 (because the eight bits in the register normally correspond to CHR A17..A10).
Post Reply