The discussion in that other thread made me made this chart, so anyone can easily figure the "minimal" mapper requirement.
Only the Nintendo mappers are included, because if I wanted to include all 3rd party mappers it would be way too complex.
The chart :
a) Need to switch large page of tilesets rapidly ? (need for CHR-ROM)
yes -> b)
no -> c)
b) Need to do pixel effects on individual tiles ? (need for CHR-RAM)
yes -> Use mapper 119 (MMC3, TQROM)
no -> d)
c) Need to do pixel effects on individual tiles ? (need for CHR-RAM)
yes -> g)
no -> j)
d) You'll use CHR-ROM. Need 512kb CHR-ROM ?
yes -> Use MMC5
no -> e)
e) Need more than 8kb WRAM ?
yes -> Use MMC5
no -> f)
f) Need 512kb PRG-ROM or 256kb CHR-ROM ?
yes -> Use MMC3
no -> g)
g) Need scanline counter ?
yes -> Use MMC3
no -> h)
h) Need WRAM ?
yes -> Use MMC1 (or MMC4)
no -> i)
i) Need to change mirroring during the game ?
yes -> Use MMC1 (or MMC2)
no -> k)
j) it doesn't matter if you use CHR-ROM or CHR-RAM.
Total amount of data >512kb ?
yes -> Use MMC5
no -> g)
k) Use discrete logic mapper.
Total size <=40kb ?
yes -> use no mapper
no -> use another discrete logic mapper (AxROM, CxROM, BxROM, GxROM or UxROM)
What about 32k of CHR-RAM?
How about MMC3 with CHR-RAM when only boards that have the pins are early SMB2 boards?
Dwedit: Does any Nintendo board even support big CHR RAM? I can't think of any, apart from CPROM. Otherwise, any mapper supporting both CHR ROM and CHR RAM would probably work.
3gengames: That and Mega Man 4, Mega Man 6, and Ninja Crusaders. I think this article assumes that bunnyboy might start offering a ReproPak MMC3.
tepples wrote:
Does any Nintendo board even support big CHR RAM? I can't think of any, apart from CPROM.
This is pedantic, but I've been pouring over the wiki too much lately, and mapper 96 supports 32kB in a strange layout.
And to get double pedantic,
the game using that mapper isn't on a Nintendo board. But it looks almost as if CPROM and MMC2 had a baby: reading from PPU $2000-$2FFF selects a CHR RAM subpage from bits PA10 and PA11.
I would like to have a mapper chart in form of a single table, i.e. one row - one mapper, and all the capabilities are listed (size of banks, number of banks, mirroring, etc).
Something like
this table?
I wouldn't really recommend producing any game using the MMC2 or MMC4 today unless you had a really good reason for using its CHR ability.
I realize this is meant to be Nintendo boards/mappers/concepts
only but...
MottZilla wrote:
I wouldn't really recommend producing any game using the MMC2 or MMC4 today unless you had a really good reason for using its CHR ability.
Keep in mind that, Memblers' 8T-ROM is has is similar to them with his PPU 'interupt.' Although I don't think it's WRAM that gets you to MMC4 with Bregalad's chart.
dwedit wrote:
What about 32k of CHR-RAM?
His board also has 32KB CHR-RAM
http://nesdev.com/bbs/viewtopic.php?t=8235
tepples wrote:
Something like
this table?
Yes, thanks.
I made a small fix since yesterday.
I excluded non-Nintendo mappers (as I said in my 1st post), and it's true I excluded CPROM too because it's very specific. Switching CHR-RAM pages is interesting but doing it while being limited to 32kb PRG-ROM is not.
Also I don't really recommend MMC2/4, I just included them so I could include (almost) all Nintendo mappers in the chart. I just add them at an option when I recommend the MMC1.
PS : Tepples, your table is great and is a great addition to the wiki.
Hey, you forgot a couple of questions, like "Do you want to make carts?" and "Is the MMC1 register write protocol brain-damaged?"
But seriously, this is a very well thought answer to an FAQ that's not amendable to a simple one size fits all reply. Inspired by this, I turned it into a flow chart.
PFD (US Legal)
SVG Source
Please proofread this. I think it's a correct adaptation, but it'd be nice to have someone else look it over.
Fix your links, they all go to the PNG file. And the last question is backwards.
Quote:
Do you want to make carts?
If yes, then use a discrete logic mapper as you'll avoid the pain that programming CPLDs in verilog is...
Quote:
Is the MMC1 register write protocol brain-damaged?
It is not so brain damaged in the sense that this allowed to connect only 2 data lines (D0, D7) to the chip. If you were to have a standard parallel write procedure, they'd have to connect 5 data lines, so 3 additional pins, the chip would have to be 28 pin (27 pins chips doesn't exist obviously).
Bregalad wrote:
It is not so brain damaged in the sense that this allowed to connect only 2 data lines (D0, D7) to the chip.
Obviously there are reasons for it, but it's still brain-damaged. It completely invalidates the possibility of switching banks for quick tasks, such as loading a few bytes, because the overhead is too damn high. The amount of bank switching you can do in a single frame is severely reduced with the MMC1, IMO.
About making carts, you don't have to be limited to the discrete logic mappers (although I do think this is a good idea), since there are a few people making CPLD mappers you can buy.
I don't see much reason to switch PRG-ROM banks a hundred of times in a single frame. If you have to do that you'd probably have to re-organize your data in a different way no mapper what you use, because even if the MMC1 wastes more time than most mappers, bankswitching wastes time on any mapper.
Say you have more than 16 KiB of data compressed using a static dictionary, but this dictionary won't fit into the fixed bank along with the rest of fixed-bank code. An e-book reader or an RPG's dialogue might be like this. The naive implementation would require switching back and forth between the dictionary bank and the compressed text bank after each word, and this might actually work for something like UNROM. A less naive implementation would bankswitch to the text, copy the data verbatim to RAM, bankswitch to the dictionary, and decompress it against the dictionary.
Think of the bankswitching time as like a TLB miss penalty and look up cache-friendly algorithms.
You're right this would be an embarrassing situation. You can't waste RAM to handle data from the compressed bank as you'll need RAM for the uncompressed data, and you can probably not waste RAM for the dictionary/decompression code either for the same reason. I'd say the best way would be to have the decompression in the fixed bank at all costs and put something else that takes up place in the fixed bank elsewhere.
I haven't worked really hard on compression on the NES yet but I plan to. Also I haven't ever worked really hard on PRG bankswitching either, as I personally never used that in my projects yet.
Bregalad wrote:
Also I haven't ever worked really hard on PRG bankswitching either, as I personally never used that in my projects yet.
I can tell you that sometimes it's really hard organizing the data in a way that minimizes the number of bank switches.
For example, I'm using 32KB bankswitching, and I have the game engine in one bank, but the level data is scattered across other banks. So whenever I have to draw a row or column of blocks for scrolling, I have to call a subroutine in the bank where the level map is. Whenever a character has to check the map for collisions, same thing. Whenever an object is erased from the background and the original background has to be restored, more bankswitching.
That doesn't add up to hundreds of bankswitches, but I expect to need around a couple dozen of them per frame... With an MMC1 that would mean over 2200 cycles wasted on bankswitching... That's nearly 8% of the total time for game logic, which is unacceptable. In a common discrete logic mapper that figure goes down to less than 2% of the total time.
Bregalad wrote:
You can't waste RAM to handle data from the compressed bank as you'll need RAM for the uncompressed data
This buffer to hold compressed data can overlay the decompressed data or overlay OAM.
I do an "interbank fetch" in my multicart project, whose mapper doesn't have a fixed bank. The menu puts a small piece of code in RAM that switches to a bank with compressed CHR data, copies some to a buffer elsewhere in RAM, and then switches back to the menu bank with the decompression code. The second switch has to scan the reset stub for a $FF byte so that it can get back home to the menu without a bus conflict, which is at least as expensive as the MMC1 write sequence. I call this subroutine once in ordinary frames; two switches per frame isn't too bad.
Of course, you don't need to go to quite as much trouble if you aren't making a multicart because then you have a fixed bank.
Why not a Windows program that you can select the features & the proper mappers remains? Like...
- full list -
[v] CHR RAM
- a few mappers are gone -
[v] PRG ROM switchable at $8000 and $A000 (16k)
- more mappers gone -
...
Is this a bad idea, instead of a chart?
Zepper wrote:
Why not a Windows program that you can select the features & the proper mappers remains?
Because not all PCs come with Windows, and not all developers of Windows applications are interested in fixing bugs that pop up only in Wine or Mono. I imagine more people have HTML browsers than Windows PCs. But with that nitpick out of the way, I find your wizard idea interesting.
Perhaps in Java..?
For something this simple you don't need anything more than good old JavaScript!
I just used HTML.
Mapper wizard
"You will be using CHR RAM. You can have a scanline counter to do raster splits, or you can have PRG RAM, but you can't have both (at least without destroying a Japan-only game)."
Out of curiosity what game/board is this?
This is wrong, you don't need to "destroy a japan-only game" (he means Destiny of an Emperor II and Final Fantasy III) to simulate TNROM with the power pack.
Then if you want to make carts just clone the MMC3 with a CPLD which is nothing complicated to do it just requires some (expensive) CPLD programing tools and some SMD soldering skills (both of which I personally lack).
Tepples, your program is great, and definitely more complete than my chart ! However it asks many questions at once, but I guess it simplifies the logic.
As for TNROM on PowerPak, I'm aware of this bug. I'm treating "yes carts" and "no carts, yes PowerPak" as the same, and I don't really have a separate decision tree for "no carts, yes PowerPak". Really the only reason I have the "do you want to run on carts" and "do you want to run on PowerPak" questions is to weed out people who get Hello World running in Nesticle and then think they're NES programmers.
I could change it to remember the "no carts, yes PowerPak" choice, but then I'd skip MMC5 screens because I lack faith that the PowerPak's MMC5 is perfect, and I'd make PRG RAM available with all of Nintendo's discrete mappers. I'd also have to make a choice: either make it in JavaScript (and have it fail for users who use NoScript) or make it in PHP (and have it fail when run offline). And at that point, I'd probably put a question distinguishing donor carts from virgin carts earlier in the sequence.
Bregalad wrote:
Then if you want to make carts just clone the MMC3 with a CPLD
I'm excluding configurations requiring equipment and skills that others, like you, are likely to personally lack. Once bunnyboy makes such a ReproPak MMC3 board available, remind me and I'll revise the entire MMC3 section.
I don't have anything against bunny boy but depend exclusively on ONE guy is not a good decision if you want to produce carts. He's likely to take advantage of his monopole position and to charge the MMC1/3 CPLD clone carts much more expensive than it'll be to someone who have the appropriate tools and soldering skills.
But anyways someone making carts for a new NES game will probably not make that many, so this should be taken into consideration too.
Bregalad wrote:
I don't have anything against bunny boy but depend exclusively on ONE guy is not a good decision if you want to produce carts. He's likely to take advantage of his monopole position and to charge the MMC1/3 CPLD clone carts much more expensive than it'll be to someone who have the appropriate tools and soldering skills.
But anyways someone making carts for a new NES game will probably not make that many, so this should be taken into consideration too.
I don't think it's fair to say he has a monopoly. There simply hasn't been anyone else who's even tried really. And like your saying about quantity, he's making a large quantity and charging much less than it would cost an individual to make a few. A PCB for $4 and a PCB w/CPLD for $9 is pretty cheap, you're going to spend $30-50 for 3 PCBs unless you etch it yourself.
I'd like to whip up the MMC3 on a board myself, but it's just a matter of actually doing it. That and I realize how people would like the capabilities for producing a game with MMC3 but how many games would actually get produced that would use it? There's only a few games being developed that would make use of MMC3 to my knowledge right now.
Ok, links and question K fixed. Thanks, Dwedit for spotting that. I also exported the PNG at a larger DPI so one can actually read it. I hope I didn't make it too wide and make the thread require horizontal scrolling (I hate that).
Thanks Bregalad for the hardware perspective of why the MMC1 would be like that. From the little hardware dabbling I've done, I can appreciate the value of reducing the pin count. But from software (my strong side), it just seems weird.
Bregalad wrote:
I don't have anything against bunny boy but depend exclusively on ONE guy is not a good decision if you want to produce carts.
For me, the main problem with this is not the monopoly (others are free to offer the same service in case they want to), but the possibility of something happening to bunnyboy. If he decides to change business, dies, wins the lottery and gives up working, whatever, we're screwed, because he's the only one around who's able to make new carts without cannibalizing anything from old ones.
Change business = post everything I have to a website somewhere
Dies = my wife knows who to send my hard disk to, they would do the above because they have their own jobs
Wins lottery = do this all for free! There are plenty of projects like the expansion port I could do when I am willing to lose lots of money
Anything else and theres a few people who could choose to do the same thing. kevtris/memblers/thefox/loopy should be able to do it immediately without any problems, others like marshallh/infiniteneslives could do it probably after learning a bit more.
But for the original topic the html version picked the same mapper I decided on for a few projects, so good job! It seemed like there were too many (overlapping?) questions about mem size. Maybe those are just needed to narrow it to a single mapper instead of a couple?
Some of the wording could probably be changed for more beginner developers too. Pages like the CHR ROM "page of tiles" might be confusing. Referring to background animations instead (or add game examples?) could help.
Might also want to add extended mappers, like the bigger B*ROM used by Action 53 and 512KB U*ROM used by BK2.
bunnyboy wrote:
Anything else and theres a few people who could choose to do the same thing. kevtris/memblers/thefox/loopy should be able to do it immediately without any problems, others like marshallh/infiniteneslives could do it probably after learning a bit more.
Agreed and challenge accepted
bunnyboy wrote:
the html version picked the same mapper I decided on for a few projects, so good job!
Heh, it was the exact opposite for me! XD I was trying to land on B*ROM (maybe it's not considering the extended version?) but it gave me friggin MMC1, which I absolutely hate!
bunnyboy wrote:
But for the original topic the html version picked the same mapper I decided on for a few projects, so good job! It seemed like there were too many (overlapping?) questions about mem size. Maybe those are just needed to narrow it to a single mapper instead of a couple?
If you're in the "doesn't matter whether I use CHR ROM or CHR RAM" track, a lot of questions are needed to distinguish SUROM from SKROM/SLROM. Perhaps I could tweak the wording to make it more of a binary search than a linear search.
Quote:
Some of the wording could probably be changed for more beginner developers too. Pages like the CHR ROM "page of tiles" might be confusing. Referring to background animations instead (or add game examples?) could help.
I agree. I just used Bregalad's wording for the early pages because it was late at night and I couldn't think of a better way to explain that one. It's just that I don't remember playing a lot of NES games that change a heck of a lot of tiles in each frame. Even Super Mario Bros. 3 uses only a few tiles from its animated bank ($0800-$0FFF) in each level, like the spinning coins and the spinning ? blocks, and those could probably be blasted to CHR RAM.
Quote:
Might also want to add extended mappers, like the bigger B*ROM used by Action 53 and 512KB U*ROM used by BK2.
I've tested 512 KiB B*ROM on a PowerPak but not yet 512 KiB U*ROM. The latter would need a 74377 instead of a 74161. How big does the discrete ReproPak actually go in that configuration?
tokumaru wrote:
I was trying to land on B*ROM (maybe it's not considering the extended version?) but it gave me friggin MMC1, which I absolutely hate!
It's treating B*ROM as having three PRG bank bits like AOROM, or a total of 256 KiB of PRG ROM. If you choose no IRQs and either 257-512 KiB of total data or switchable mirroring, you end up with SUROM or SKROM/SLROM.
tepples wrote:
It's treating B*ROM as having three PRG bank bits like AOROM, or a total of 256 KiB of PRG ROM.
But AxROM actually uses the 4th bit for something (mirroring), unlike BxROM, so it doesn't make much sense to not use that bit to double the capacity of the mapper.
Off topic but related to the cart manufacturing replies so far..
Why hasn't anyone made something similar to the Melody cart by AtariAge?
http://atariage.com/store/index.php?l=p ... age_melody
Wouldn't an open sourced piece of hardware similar to that solve many problems at once?
tokumaru: BxROM isn't even listed in
the board's manual; it's a modification of the board's support for AxROM that bunnyboy and I discussed one day. The 161 is in the position for AxROM, but you solder the HORIZ or VERT pads instead of the ONE pads. I don't even think there's a trace for PRG A18.
slobu: Say someone made a reprogrammable NES cartridge. Which mapper would this board implement? There are a lot more mappers on the NES than on any other 8-bit platform because only the NES has CHR ROM. But as I understand it, the 8T-ROM is supposed to be something like the Melody board. And once it comes out and gets emulated, remind me and I'll update the wizard. Right now the closest thing, a board reprogrammable for multiple discrete mappers, might be a PowerPak Lite with its PRG RAM replaced with flash memory.
As for the CHR ROM vs. CHR RAM section, is the wording in
this wiki article OK?