INTRO

I had a request for MMC1 mapper information, so I thought everyone might like to read what I have to say.

This will help you figure out MMC1 memory mapping.  It assumes that you have a working knowledge
of NES programming and can understand my messed up little mind. Most of the information on this
mapper can be found on:

http://wiki.nesdev.com/w/index.php/MMC1

MMC1 will allow you to use up to 256 kB of PRG ROM and 128 kB of CHR ROM.  I think that you can use SUROM to expand up to 4 MB of PRG ROM, but this is not covered here.

First, you have to decide on what kind of configuration you want to use.  MMC1 will support PRG bank
switching in either 16kB mode or 32kB mode.  And with the 16, you can choose whether you want
the memory at $C000 or the memory at $8000 to be switched. 

Second, you have to decide on the CHR ROM switching.  MMC1 supports switching of 4kB (background or sprite tiles separately) or 8kB (switching them together).

After you decide this, you are ready to start.

INES HEADER

Notes:

-You can only have even numbers of PRG banks.  NESASM uses 8kB "banks", I'm talking about 16kB banks. 
i.e. 02 (32kB),04 (64kB),06 (96kB),08 (128kB),0A (160kB),0C (192kB),0E (224kB),10 (256kB)

-CHR banks are in multiples of 8kB banks. (important if you are using 4kB swapping.)
i.e. 01 (8kB),02 (16kB),03 (24kB),04 (32kB),05 (40kB), 06 (48kB), etc., 10 (128kB)

-MMC1 mapper number is "1" ...creative!

-Mirroring should match that used below in the initiation routine.

In this exercise, we will use:

  .inesprg $10   ; 16x 16KB PRG code
  .ineschr $10   ; 16x  8KB CHR data
  .inesmap $01   ; mapper 1 = MMC1, 4KB CHR bank swapping
  .inesmir 0   ; background mirroring

MAPPER CONTROL HEADER

This is one bite that has all the information for the mapper.  Observe:

76543210

Bits 7,6,5 - Not sure what these do.
Bit 4 - CHR ROM bank mode - (0 means switch 8kB at a time, 1 means switch the two separate 4kB banks independently)
Bit 3 - PRG ROM bank mode - (0 means switch all 32kB at once, ignores bit 2)
                            (1 means switch ONLY the 16kB specified in bit 2)
Bit 2 - PRG ROM location - (0 means switch 16kB at $C000, 1 means switch 16kB at $8000)
Bits 1,0 - Mirroring - (0 means one screen, lower bank; 1 means one screen, upper bank
                       2 means vertical; 3 means horizontal)

Here we will use LDX #%00011000

BITCH WORK!  Look above and figure out what this means.

INITIATE MAPPER

Here we load the information required by the system to run the mapper as well as the initial banks.
You have to do the 5 writes to make it work...for whatever reason.

initMMC1Mapper:
  LDA #$80                     ;this locks the PRG ROM at $C000-$FFFF to the last bank.
  STA $8000
 
  TXA                          ;uses our header to initiate the mapper
  JSR setMMC1ControlMode
 
  LDA #$02                     ;sets the CHR information for the sprites
  JSR setCHRPage0000
 
  LDA #$01                     ;sets the CHR information for the background
  JSR setCHRPage1000
 
  LDA #$03                     ;sets the PRG information
  JSR setPRGBank
 
  RTS
 
setMMC1ControlMode:
        STA $8000
        LSR A
        STA $8000
        LSR A
        STA $8000
        LSR A
        STA $8000
        LSR A
        STA $8000
  RTS
 
setCHRPage0000:
        STA $A000
        LSR A
        STA $A000
        LSR A
        STA $A000
        LSR A
        STA $A000
        LSR A
        STA $A000 
  RTS

setCHRPage1000:
        STA $C000
        LSR A
        STA $C000
        LSR A
        STA $C000
        LSR A
        STA $C000
        LSR A
        STA $C000
  RTS
 
setPRGBank:
        STA $E000
        LSR A
        STA $E000
        LSR A
        STA $E000
        LSR A
        STA $E000
        LSR A
        STA $E000
  RTS

Congrats....your program should work.

USING THE MAPPER

You can swap out banks whenever you want, even several times per NMI.  Just load the bank number you want to
use into A and call the appropriate subroutine.  Just be sure that you don't switch away information that
your program needs to run or it will die.

Weird bank numbering notes:

-CHR data is stored in 8kB for NESASM.  If you want to call the first 4kB of data from the 6th 8kB chunk,
you would use bank #$0C.  Observe, call number for 4kB chunk vs. 8kB bank number:

00-0
01-0
02-1
03-1
04-2
05-2
06-3
07-3
08-4
09-4
0A-5
0B-5
0C-6
0D-6
0E-7
0F-7
10-8
11-8
12-9
13-9
14-10
15-10
16-11
17-11
18-12
19-12
1A-13
1B-13
1C-14
1D-14
1E-15
1F-15

Clear?

-PRG info is stored in 8kB chunks in NESASM, but you call and switch 16kB banks.  If you want to call bank 26, use call number #$0D.  Observe, call number vs. bank number:

0-0,1
1-2,3
2-4,5
3-6,7
4-8,9
5-10,11
6-12,13
7-14,15
8-16,17
9-18,19
A-20,21
B-22,23
C-24,25
D-26,27
E-28,29
F-30,31

Clear?

-At the end of each 16kB bank, you have to have vectors in place or it will die.

  .org $FFFA     ;first of the three vectors starts here
  .dw NMI          ;when an NMI happens (once per frame if enabled) the 
                          ;processor will jump to the label NMI:
  .dw RESET    ;when the processor first turns on or is reset, it will jump
                           ;to the label RESET:
  .dw 0               ;external interrupt IRQ is not used in this tutorial

-Bank numbering is successive.  i.e. if you have PRG banks numbered 0-23, you would start numbering your CHR banks at 24.

-If you have, for example, a 16kB CHR file, you only have to include the starting place and NESASM will
split the banks properly. i.e. in 4kB mode:

  .bank 32
  .org $0000
  .incbin "MMC1.chr"   ;includes 16KB graphics file

This will include 4 - 4kB (or 2-8kB) banks in the assembly process.  Be sure to account for the 2 banks
in your numbering.  (see the attached ASM file.)

PRACTIAL APPLICATION

This is a little inefficient.  To use all this nonsense in something real, an example would be:

LoadBackground:

;find room info

;switch to room info table bank

;load bankground pointer

;switch to bank where background information is stored

;load background

;switch back to room info table bank

;load attribute and palette pointers

;switch to attribute/palette information bank

;load attributes/palettes

;switch back to room info table bank

;load collision detection pointer

;switch to collision detection bank

  RTS

WORKING EXAMPLE

Here we use the controller to switch banks for both CHR banks and the PRG bank.

A and B - swap out CHR information for the sprites
Select and Start - nothing
Up and Down - load a background located in different banks (the flashing is cause you are holding the button
down for more than one frame.  Just tap it.  I was too lazy to add stuff in to fix this.)
Left and Right - swap out the CHR information for the backgrounds

Download the attached file and assemble the program.  Mess around with it and try to switch out the
various buttons and banks.  Fix the flashing.  Add new backgrounds and characters...etc.

The little DOS assembler file might not work, you may have to edit it to your drive.

THE END!

I'm sure I totally screwed this up, but don't worry!  Someone will help me out if there are any mistakes.

Thanks MRN.

No problem. Feel free to PM or post if you have questions.

While technically you can make your PRG in all those sizes, there's no guarantee that all emulators will load sizes other than 32kB, 64kB, 128kB, 256kB, 512kB, etc.  Some emus will want to start in the highest numbered bank, which is problematic if the ROM is abnormally sized.

Though in my experience with an MMC1A, it started in a random 32kB bank.  So you may need a copy of the vectors and some startup code in every 32kB bank, that's easy enough.

I'm trying to write code for the MMC3 mapper, and somewhere I'm getting it wrong. Do any of these stand out:
1) I'm using asm6 and inside the header I'm telling it 8 PRG banks, with %01000011 as control byte 1

2) My code for setting up the banks is basically:
.base $8000
.include "firstbank8000.asm"
.pad $A000

.base $8000
.include "secondbank8000.asm"
.pad $A000
etc.

at the end, I have
.base $E000
;code for interrupt vectors
.pad $FFFA

.dw NMI
.dw RESET
.dw 0

.incbin "graphics.chr"

3) Something I noticed - when I assemble and run the .nes file, I'll get a gray screen, and when I open up the debugger there is nothing in the $FFFA-FFFF (UNDEFINED). Does that mean the RESET: code didn't run, or does it mean that the RESET label was never added to FFFC-FFFD in the first place?

4) How do bank numbers work with MMC3? Is there some sort of internal counter that increments every time I use a .base $8000 or .base $A000 (.base in place of .bank, since I'm using asm6)? I'm trying to learn how the program understands my write to $8001 to do the bank switch, especially when I don't have statements such as ".bank 2."

If FFFA-FFFF is undefined, it means that the reset label was never added to FFFC-FFFD in the first place.

What exactly do you mean by "control byte 1"?  MMC3 let's you choose between having $8000-9FFF swappable or $C000-DFFF swappable.  Your code is written like $8000-9FFF is the swappable address space.  Could it be that your value for "control byte 1" is selecting the other mode ($C000-DFFF swappable)?  See the nesdev wiki article on MMC3.

Can you zip up your asm files and attach it?  It would be easier to help if I could tinker with the source and see if I could get it working.

If your header says you have 8 PRG banks (128KB) but your code only sets up 1.5 banks (24KB) then the emulator probably can't load it correctly.

^^^ I can attest to this being a problem. Mine worked in FCEU but not in Nestopia when I didn't have enough banks in my assmebly doc.

Also, for those in the future who have the same problems I have. Mirroring is handled in the LDX #%00011000. Changing the header won't matter.

Thank you guys. When I mentioned control byte 1, I was referring to the 7th byte of the iNES header (where you have to tell it the low 4 bits of the mapper number).

The good news is that the code is now working (I am doing a joint project with another guy, and he saw where the error was). The spot where the bank switch was occuring needed to be set a little earlier in the code.

Also, the MMC3 uses 8KB banks, but the iNES header needs to know 16KB banks? So, if you have (6) 8KB banks of code, you have to tell the the header "3" banks?

Did you guys have an answer to my question #4 by chance? I'd love to get an explanation on that.

Why were the posts by deleteme removed? They were finally formatted well and brought up very valid points that nobody else would.

Why don't you PM me a list of said points and we'll see what we can do to fix them.

Someone took the literal interpretation of his username?

Ba-dum-pshhhh

How about you actually read posts before abusing your Mod Squad powers to delete them? Well formed criticism just gets erased like nothing happened, yet I was the one that people attacked. How sad is that? I hope BunnyBoy agrees with me or even has a chance to read this before it gets deleted again.

Incomplete and buggy tutorials should not have the Nerdy Nights name attached, especially without ever asking permission. Is it that hard to come up with your own name instead of piggy backing off others?

I wouldn't necessarily say he was "piggy backing." He just wrote up a helpful guide for me that had to do with background compression. Its focus being NES programming, it makes sense to me to just use the same name that other NES programming tutorials were using.

There was no intent to do nothing but help promote the NES dev scene by doing these posts. He started the post with a disclaimer to let people know that it wasn't promised to be 100% accurate. I don't see anything wrong with that.

If you are programming your own game and used his tutorials here and they somehow messed up what you were doing I could understand the hostility here, but I don't see any harm with his coming in here trying to write a guide for someone less informed (me) to use.

He just used the Nerdy Nights name because that's what people have been calling their NES dev turorials. Did Metal Slime ask permission to use the NN name when he did his music tutorials? I don't know this answer, but I don't see people hounding him about stuff.

Relax. This was all done with the sole purpose to help others.

Yes, MetalSlime did ask and was given permission. He also sent me his first few tutorials so I could read and edit them. Changes were made to make his stuff match the series and make them more complete. He also really understands the entire audio system instead of still being a a self described noob.

The problem is these tutorials are buggy and incomplete. As deleteme said before it was erased, things like "Not sure what these do" should never be in a tutorial. Previously I let things like that go because any tutorials are helpful.

But now since there has been no notice that all the deletion even happened, no explanation for removing valid content, and no apology to deleteme I am now requesting that nobody use the Nerdy Nights name without contacting me and having complete tutorials. This isn't to stop anything from being posted, just use your own name instead. Of course I can't actually enforce this and likely won't bother trying. To clear up the gaps in this specific tutorial another one will be posted.

SNAP! That man needs another icon *suggestion*

Fixed!

Wow all that to avoid an simple apology, and yet still the tutorial has problems!
A: INES header mirror info is wrong
B: nothing about batt ram
C: still doesnt explain about the reset
D: wrong caps on kb
e: misspelled words
F: doesnt explain bits7,6,5
G: etc etc etc
why miss the chance to make it better? At least BunnyBoy fixes his shit when an error is found...

"Someone will help me out if there are any mistakes." and when help came it was deleted. Will you take the help now?

My point was to give someone the code to make a working program with a working understanding.  Not to explain exactly what everything did and why.  That's why I referenced NesDev wiki. 

I like helping people too.    I think the person may have just been in a bad mood.

You should change the caps on kb.   It actually is important.   The k doesn't matter.  The b does.

Thanks for the help Al. I changed the kB, I think I got all of them.

But on the bits, I think that our friend here meant bits 7, 6, and 5 of the "Control" not the "Load Register" (as nesdev wiki puts it). But I will add that part about the load register that you pointed out. Thanks!

I would expect the apology to be for deleting all his posts, as they were far more detailed and helpful to corrections than the subsequent ones. My bad mood is because that info was erased instead of actually read to make everything better. Corrected tutorials lead to better programmers, while bad information lasts forever (see buggy GBAGuy tutorials). I care about the quality of the materials linked to the name, not who generates it.

iNES header - mirroring is completely ignored, so saying it should match isn't quite right. Not sure its "wrong", but that could (and has) caused people problems. Claiming you are using four screen mirroring actually is wrong. Your .inesmir would have to be 8 for the four screen bit to be set.

Misspelled words are very important for anyone who does not have english as their first language. Bite and byte are two completely different things, just like KB and Kb. As groups like playpower.org introduce more second and third world users to the NES through cheap clones the wordings in tutorials will become more significant. Of course "so what" is a valid excuse if this is only meant for a couple people

Bit 7 is the reset. This is very important, like reading $2002 to reset the hi/lo latch. It also changes registers to default settings, which could change your PRG banking layout immediately. If your initMMC1Mapper code is in a bank other than the last 16KB it could be swapped away, crashing your code.

Bits 6 and 5 do not exist, because it is only a 5 bit shift register inside the mapper.

Am I in minority for thinking he shouldn't have to apologize? Was there any need for all the negativity right from the beginning? Since deleteme started posting in this thread, his post count has doubled. I wouldn't call that a positive contribution to the community. It would have been quite possible for deleteme to criticize without being an ass about it. I can understand why you would be a little peeved, since the Nerdy Nights are "your baby".

Regardless, it is still helpful, thanks MRN for this info and Bunny for all the help you guys give to us meager homebrewers.

Except the posts that were erased had all the errors/issues listed above and more corrections needed. Unfortunately not everyone saw them and only the unhelpful angry and painfully formatted posts were kept, I assume to make him look bad. The posts by MRN challenging him in the other thread were also deleted. Where is that undelete post button to show all that?

Yeah, if we can split the posts off, I'd like to talk about that. I think deleteme brought up good points, but was a dick about it to start with. I read his posts and thought, "damn... dickish!," but bunny brings up great points about it. Either someone starting a new topic, or splitting the last couple of posts here would be great. I think discussion about how info is presented about development would benefit all of us.