Mapper recommandation chart

[tokumaru]

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.

[Bregalad]

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.

[tepples]

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.

[Bregalad]

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.

[tokumaru]

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.

[tepples]

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.

[Zepper]

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?

[tepples]

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.

[Zepper]

Perhaps in Java..?

[tokumaru]

For something this simple you don't need anything more than good old JavaScript!

[tepples]

I just used HTML.

Mapper wizard

[infiniteneslives]

"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?

[lidnariq]

Looks like TNROM, used in FF3j, Pachio-kun 4, and Tenchi o Kurau II: Shokatsu Koumei Den.

[Bregalad]

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.

[tepples]

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.

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.