Number of possible CHR banks

I am new at this and I was wondering how many CHR banks are possible to be able to swap through? Also, I have a .chr file that I use to draw tiles and I would like to make it bigger so it will hold more banks than just the 256 sprite and 256 background. I compile using NESASM3 if that makes a difference.

It all depends on the mapper - the NES-CNROM-* board (iNES mapper 3) can support up to 32KB, the MMC1 (mapper 1) can handle up to 128KB natively, and the MMC5 (mapper 5) can handle 1MB. If you're designing your own mapper, you can theoretically make it as big as you want, but a standard .NES file (non-V2) will max out at just below 2MB.

Depends on the mapper used. You didn't disclose that for whatever reason. :-)

If you're still deciding what mapper you're gonna use, you have to consider the type of CHR switching you want to do. If you want to swap the whole 8KB at once, CNROM is the best option. With just one mapper write you select a different 8KB page of CHR (you can have up to 4 pages, or 32KB). CNROM doesn't expand PRG-ROM at all though, it's still limited to 32KB. More complex mappers will allow you to swap CHR in smaller pieces. For example, the MMC1 has 2 4KB slots (so you can swap sprites and background independently), MMC3 has 2 2KB slots and 4 1KB slots, and more complex mappers can do 8 1KB slots, which is as fine as it gets.

If you don't need instantaneous CHR bankswitching, you should also consider CHR-RAM. CHR-RAM means that the 8KB used for tiles are empty when the program starts, and the program is free to write whatever it needs to it (using $2006/$2007, just like with name table and palette writes). This will allow you to rewrite any portion of the pattern tables you want, down to a single byte if you want to. The disadvantage of CHR-RAM is that updating it takes time (the time used for LDA'ing and STA'ing each byte times the number of bytes), while CHR-ROM bankswitching is instantaneous. This means that CHR-RAM updates are not suited for a complex title screen with more than 512 tiles, only instantaneous bankwitching halfway through the screen will give you that. However, if you plan to update the tiles only between levels and can afford to go a couple of frames with rendering turned off, CHR-RAM is a great (and simple) option.

I am relatively new to this so I used the Nerdy Nights tutorials to get going. I am doing great at the programming part but there are a lot of things about how the Nintendo really works that I'm still learning. In the Nerdy Nights tutorials, they have the following settings as the first lines of code. I have continued to use this setting and I have a better-than-vague sense of what they actually do. The comments are obvious but I still haven't figured out how to make the game save. (I realize it has something to do with the ability to write in the $6000-$7FFF range)

.inesprg 1 ; 1x 16KB PRG code
.ineschr 1 ; 1x 8KB CHR data
.inesmap 0 ; mapper 0 = NROM, no bank swapping
.inesmir 3 ; background mirroring

QUESTIONS FOR EVERYBODY:

How do I allow writing onto $6000-$7FFF?
Is there a list of what every .inesmap number stands for?
Is there a way to gauge how much PRG memory my code takes up as a whole and how many cycles it took to run per frame?
How can I expand the size of the CHR file I use so that it will hold more than the original 4KB of tile data?

Thanks everyone.

What are you trying to save? If it can be squeezed into 32 bits, I can help you design a password system.


By adding a 6264 SRAM, 7420 decoder, and various diodes onto the board. The .inesmir 3 tells the emulator to include these components.


See the grid or list.


Open it in a hex editor and see where the 00 00 00s start.


A debugging emulator such as FCEUX should let you put a breakpoint on your "wait for vertical blanking" subroutine. It may show you the current scanline number (1 scanline = 113.67 cycles) or the number of cycles since the last breakpoint (helpful with breakpoints at the start and end of vblank wait).


That depends on several things. First, how are you creating this CHR file? Second, how you organize the tile data in CHR ROM depends on what you want to display at the same time. Show mock screenshots throughout the game and we might be able to recommend something. Third, you can include extra CHR ROM as extra banks after the PRG ROM, but how you actually use the data in those banks depends on the mapper you choose.

What I am trying to save is only 16 bytes. I have set inesmir 3 in the beginning and I have tried making writes to $6000-$600F. The hex editor confirms that the writes are not being made. Only setting inesmir to 3 is apparently not enough.

Ideally, I'd like to swap out only 128 background tiles at a time (I think 2KB worth) and have the largest CHR file to work with.

Which emulator are you using? I can see three reasons why saves might not be saved:

• Some emulators might not support saving with mapper 0, despite that configuration having been used for Family BASIC.
• You may first need to tell the emulator where to put the .sav file. Some emulators assume that the folder containing the ROM is read-only, such as when the ROM is in a shared folder that multiple users on your computer can read but not write, or when it's on a CD or DVD.
• Some emulators name .sav files based on a hash of the ROM contents, which makes your saves inaccessible after you have rebuilt your program. I ran into this with Mednafen.

How quickly do you want to swap these tiles out? Do you need to swap them continuously, like the moving grass in Super Mario Bros. 2 and spinning coins and ? blocks in Super Mario Bros. 3, or are you swapping only between screens?

I am using FCEUX 2.2.2. No .sav file is being created. I believe the issue lies with mapper 0. What number should I set inesmap to instead?

What site would you recommend for learning about the advantages, disadvantages, and capacities of these mappers.

There is no official or unofficial resource for such comparisons. You will need to investigate each by hand and see which meets your needs. Your game/thing = your code = your design = your choice = your responsibility. (I say that respectfully, not judgementally) Tepples' question at the bottom of his post didn't get answered either, and the answer to that would help narrow down your choices.

I can provide the following:

http://wiki.nesdev.com/w/index.php/Mapper
http://wiki.nesdev.com/w/index.php/Comp ... do_mappers
http://wiki.nesdev.com/w/index.php/List_of_mappers

Please note the 2nd link is a comparison of the Nintendo-branded mappers; there are lots of others (Konami, Namco, etc.) which are available and were used in commercial games legitimately which you can use.

I tend to advocate use of MMC3 (iNES mapper #4) as it provides fine-grained control over CHR bank swapping (down to regions as small as 1KByte) and doesn't involve a lot of "bit shifting" + "repeated writes" to accomplish a task (i.e. a single sta statement can do swapping, rather than for example MMC1 where you need to issue several stas to accomplish swapping), plus is well-supported by mainstream emulators and hardware kits (PowerPak, etc.).

You could play with the mapper wizard. Some of the availability recommendations are out of date, as I made it two years ago when retrousb.com was still selling ReproPak and before infiniteneslives.com started selling its own boards.

I've also made a summary page on the wiki of all the remotely-well-documented mappers here:
nesdevwiki:User:Lidnariq/MMC3 Variants

I'm happy to move it from a userpage, but don't know where else on the wiki it'd belong instead.

I have experimented by changing the inesmap value from 0 to 119, still won't allow me to write to $6000. When the time comes, I want to swap out as few tiles as possible when CHR bank switching. NES-TQROM sounds like I could accomplish what I want with bank switching but is there a mapper that is considering the best when it comes to bank switching?

What do you have in Config > Directories > Battery Saves?

Sections "MMC3-like mappers with simple banking" and "MMC3-like mappers with outer banks" should probably go into a new page called "MMC3 variants" and that page should be linked to in the main MMC3 page (under References / See also) -- but before doing that, keep reading.

Section "Not-particularly-MMC3-like ASIC mappers" and "Discrete logic mappers" I have no idea what to do with.

Hrm... honestly what's needed is a table-ised page (a single page, not split across multiple pages) of all the mappers (in order of iNES mapper # and using the sortable table capability so people can sort by field) and all their capabilities/etc. summarised like what you've done throughout all those sections/tables. Words like "MMC3" in "bank style" need to become links to the MMC3 document/relevant mapper, etc. so that people can cross-reference what's what. Some of the formatting needs to be made consistent (ex. 16 + 16F vs. 16+16F (note spacing), same for TLSROM,TKSROM (again spacing)). The columns "PRG bank size" and "CHR bank size" should also have their unit specified in the column (ex. PRG bank size (kB)) else they're just arbitrary numbers.

Although I'll say this: I have no idea what "F" or "R" means, ex. 16+16F vs. 16F+16 vs. 2+6R, so a legend may be needed as well.

For ridiculous mappers that are designed by crazy idiots and consist of 9 billion things intermixed: best to just make a separate page for those mappers (or use the hopefully-existing iNES_Mapper_XXX wiki page) and clarify things there with a single row in the table saying "See {link to thingus}".

The page needs to be clear/concise to people who want a general overview of overall capabilities and not something with insane amounts of detail; what you have in "Comments" works great for a sort of "extra capabilities" line, ex. "Scanline IRQ, expansion audio", and that shouldn't get too out of control (mapper 5 / MMC5 is a good example of where it gets ridiculous). For example, I wouldn't want the page to end up looking like this clusterfuck on Wikipedia where you totally lose track of where you are + there are multiple tables for multiple things where one program is in one table but not another due to negligence on the part of the editor. TL;DR -- One mapper per row, one table. If you want me to start the page + design the existing template/layout, I can do that.

There's a .NES header bit, specifically bit #1 (2nd bit) of "Flags 6", that has to get turned on to honour use of SRAM. Otherwise the emulator will very likely not write out a .SAV file, regardless of what you have as your mapper # (the behaviour here will vary per emulator). If NESASM3 lets you toggle these bits individually, great -- if not then you'll need to edit the ROM every time after assembly to fix it (or find a tool or .bat script that lets you accomplish that).

Edit: It looks like Tepples already said how to do this in NESASM3. If you want to verify it works, just provide the hexadecimal values of the first 16 bytes of the resulting NES file and we can tell you (or you can read the page I linked and decode it yourself).

The problem is that (I think) there's a small and very consistent amount of extra information needed to describe the caveats using either (discrete logic mappers) or (mappers with outer banks); unifying all three tables will result in a lot of unused space for the other ones. That said, I agree that "not particularly MMC3-like ASIC mappers" and "MMC3-like mappers" aren't meaningfully different, so I've combined them.
Every single place it's in the table?
I don't see "R" (not as part of "RAM") anywhere ... at least anymore? I think I fixed that in the past. "F" means Fixed. I've added a legend at the top.
Problem is that MMC5, VRC6, N163, and mapper 90 are ridiculous.
I'm happy either way? If you want to make a quick mockup of how you'd finish combining things, that would probably be the least effort?

Ideally yes. While Wikipedia, when writing actual text articles, tends to advocate only linking to something once, ex: {link}Jimmy Dean{/link} Sausages are known for being delicious but will give you haemorrhoids. Thanks, Jimmy Dean! ...but these aren't text articles -- they're essentially technical reference materials.

And yeah I know -- it makes the markup significantly more ugly/more annoying to look at/edit, especially if it's data that's imported from a text file or something (I used to have to do this at my old job -- main source was just an ASCII file people edited, so every time someone changed something there, I had to go and manually fix all the words that should have [[ and ]] around them. So much wasted time...).


I found mentions to "R" and "F" here at the very bottom (I tried to go digging to find out what they meant): http://wiki.nesdev.com/w/index.php/User ... ogic_Table


Then let's leave the insanity for the main wiki pages on those mappers. In the Comment area you can just say "Extensive; see MMC5", "Extensive; see VRC6", etc.. Most of the other mappers provide an easily-summarised set of functionality.


I'll try to come up with a mock-up of what I was hoping for, with some existing examples already in place.

EDIT: Okay, I'm starting to see why this is complex as hell. I didn't realise there was so much variance between board types. Good lord! I'm thinking a good starting point would be to migrate the data from here into this page (which isn't your responsibility lidnariq :-) ), but then somehow work this data into that same page, although that's a tremendous project. It might be easiest to just take the data from your MMC3 Variants page and put it into separate section(s).

P.S. -- I have no idea what "outer banks" refers to in the "Mappers with outer banks" section. Maybe a little preface/explanation in a paragraph above the table would suffice. (I took a look at mapper 14 and I guess it's like a "dual-mode mapper" where in one mode it acts like a particular existing mapper, while in another mode it acts like something completely different. Weird...)

"Outer banks" are things you find in the multicart mappers, where individual games write to the registers of the "regular" mapper and the menu writes to a separate set of registers that chooses which game will be played. For example, Nintendo World Cup appeared on two boards that extend the MMC3 in this way: one with SMB1 and Tetris and one with Super Spike V'Ball.

Wrong, you need 2 mapper writes (to $8000 and $8001) for the MMC3 to perform any bankswitching.


Outside of the sound functionality, the VRC6 is pretty basic and doesn't do a lot more than the VRC4, which itself is a VRC2 with IRQs.

The wrong rumor of VRC6 being a "supper mapper" comes form the fact it's used in Castlevania III which also uses MMC5, which is a truly super mapper. So people started to belive the VRC6 was another super mapper when in fact it wasn't (again, outside of extra sound functionality).

But then all mappers with expansion sound should be considered "ridiculous" by your standards it seems.

I stand by my inclusion of the VRC6 in that list, because describing its full set of capabilities is noticeably longer than others in my table, a distinction shared with only the other three in the aforementioned list.

The long-debunked rumors pertaining to Castlevania 3 had nothing to do with it.

I'm talking about the VRC6 as documented in their programmers' manual and as the IC actually behaves, not the way the games use it. It's rather the combination of ROM nametables, complicated nametable layouts, WRAM, IRQ, and expansion sound that combine together to earn its rank.

I consider neither the VRC7, SS5b, nor FDS "ridiculous". I don't even consider the incomplete version of the VRC6 as we understood it in 2010 to be ridiculous.

Well, no, I consider the FDS ridiculous but for reasons that have nothing to do with its synthesizer and everything to do with Quick Disk.

I think I have completely missed something here. Are you insinuating that ridiculous features were recently discovered in the VRC6 ? If so, then my bad, I just didn't know about that.

VRAM and IRQs and arbitrary nametable mapping are definitely pretty standard features, pretty much equivalent to MMC3 functionality. I didn't know that VRC6 had ROM nametables - this is ridiculous especially since you don't want to waste 2k to store an uncompressed screen anyway, even if it is completely static (which is extremely rare in a game).

Yet, it's ridiculous that VRC7 isn't ridiculous and VRC6 is.

Yeah, that was the entire point behind the leaked VRC6 documentation in this thread, or naruko's rephrasing or natt's test ROM or the raw data I got from BootGod for the banking test.

Ok, I 100% agree with you, the VRC6 is crazy.

I just completely missed those recent findings.

EDIT : If the CHR-ROM swapping is the only new feature, then it's definitely not that complex. It is just another form of CHR bank switching, except it affects $2000-$2fff instead of the more normal $0000-$1fff zone. It is not more complicated than TLSROM boards for instance.

(Keep in mind that I am new to this) I looked at the link you provided and see that under "Flags 6" that if bit 2 is equal to 1, then this allows writes to $6000 - $7FFF. How do I change this "Flags 6" thing? What do I write and where? All I am trying to accomplish at this point is anything that allows me to save data, and recalls it automatically when the game starts. I am currently using the following configuration: (compiling with NESASM3)

.inesprg 1
.ineschr 1
.inesmap 119
.inesmir 3

You've already set .inesmir to 3.

If it's not working, you're doing something else wrong.

It'd be best if you posted a .NES file so we could figure out what's going on.