New, homebrew mapper

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

Posts: 1077
Joined: Mon Feb 07, 2011 12:46 pm

Re: New, homebrew mapper

Post by zzo38 » Thu Jun 08, 2017 1:56 pm

I think it ought to be allowed to "semi-reserve" mapper numbers (outside of plane 0 and plane 15) if you have started to work on a program using them and have defined the mapper, but somehow is not officially release yet to be permanently assigned. You can still use those mapper numbers for other purpose if you run out of other numbers to use.

User avatar
Posts: 208
Joined: Fri Sep 13, 2019 11:22 pm

Re: New, homebrew mapper

Post by aquasnake » Thu Nov 26, 2020 6:11 pm

I'm cautious about homebrew mapper, because create a new mapper, unless you really can't find another mapper that can do the same thing. Sometimes, the existing mapper already meets the demand, and I just need to expand it a little, such as adding the address line of outer PRG bank. Sometimes it is unnecessary to redefine the original mapper to occupy an nes2.0 label (if there are unused bits in the 8-bit data latched at some address). If mapper types are created arbitrarily, the nes2.0 1024 types will be used up quickly. Mmc3 variant with expanded RPG/Chr, mapper 12-115-121-123-187-219-291 of Kasheng/superone are optional, even mapper268 (mindkids/coolboy) is.

If you have developed a game for your own defined mapper, if you are willing to provide this test ROM, I can emulate and test it on my development board as soon as possible in a few hours.

After I cloned more than 90% of the single cart mappers of ines with a single hardware, I used a menu header to manage and select different mappers, and could arbitrarily combine two or more mapper functions. At this time, I did not define a new mapper type (of course, it can be regarded as a new type, but it is not necessary). Similarly, combining the different functions of existing mapper is not a necessary condition for creating a new mapper type. My opinion is, "do not multiply entities beyond necessity".

There is a case for defining a new mapper type: for a commercially released game, it needs to be "incompatible" with the existing mappers in order to protect the development results. Simply switching address data lines to change the register setting entry is not safe to prevent piracy. Logic analyzer is enough to crack this level. Moreover, for commercial release of games, we must strictly prevent the disclosure of mapper specifications

Post Reply