Doing a custom mapper - feasibility?

[Sivak]

Hey all. I was talking about this in the chat, but I wanted to bring this here for some input.

I know very little about the actual production side of things.

I have wondered about doing something that's kinda like MMC3, but not quite as "feature-rich".

Basically, this is my outline:
-Have 256KB of PRG, with 16 16KB banks. Last bank is fixed.
-Have 64 or maybe even 128KB of CHR ROM with 2KB swappable banks. 1KB would be cooler in terms of being able to animate some things, but probably too expensive.

That'd be it. No extra RAM on the board or anything like that. This, to me, would be a nice step above UxROM in terms of CHR capabilities. RAM works and is pretty versatile, just the slowness is what I don't like.

Does this sound feasible or even doable? I also heard I'd have to mod an open source emulator to make it work.

Thanks.[/i]

[Dwedit]

I'd bet that getting hold of the MMC3 clones the Chinese pirates use would be cheaper.

[tepples]

One thing you could try: Start with MMC1, such as the MMC1 clone from retrousb.com, and swap the CHR A12 and A11 lines going into the CHR ROM chip. Then register $A000 controls 2 KB banks in $0000 and $1000, and register $C000 controls 2 KB banks in $0800 and $1800.

[tokumaru]

We have talked many times about a new mapper for the homebrew community, but there seems to be a chicken vs egg kinda thing going on: nobody wants to program a game for a mapper that doesn't exist and nobody wants to make a mapper for which no games exist.

A while ago there was an interesting idea proposed by tepples, which was a very versatile mapper, but that seems to have gone nowhere.

[Sivak]

Well, if the mapper I proposed were doable, worked on hardware, and wasn't horribly expensive, and could get some support on an emulator then I'll gladly do it.

[tepples]

The consensus at the bottom of the previous topic appears to suggest the following:

1. Get a PowerPak and a sufficiently recent Windows PC.
2. Download and install Visual Studio Express and the FPGA devkit.
3. Start from the CNROM demo source and write your own mapper for PowerPak.
4. Once it's working on a PowerPak, write patches for FCEUX, Nestopia, and Nintendulator.
5. Post all this on nesdev BBS, and people on this board might help you reduce it to a CPLD-based design that you can replicate.

[Banshaku]

If I remember well, Bunnyboy seems to be working on an MMC3 clone so that should fix your issue. He barely mentioned it in this one.

[tokumaru]

I can't do half of the stuff in that list. Hopefuly someone who's more hardware-inclined will feel like taking the challenge of implementing this mapper.

I really like how this mapper uses CHR-RAM but has more than 8KB of it so that a certain level of bankswitching can be performed, it's a very good compromise between CHR-ROM and CHR-RAM.

The simple yet effective IRQ is another feature that got me really interested. Although right now I'm kinda wondering how we'd go about using multiple IRQs in a single frame... One IRQ per frame would be no problem because you could simply disable IRQs after the first one fires, but what if you want another IRQ further down the screen? Would an IRQ fire for each scanline of the accessed tiles? Would it be possible to fire IRQs only for the first row of the special tiles?

Also, like I said on the other thread: don't underestimate the PRG-ROM size, specially since it will have to hold all graphics as well. I feel like it has to support at least 1MB for it to be reasonably future-proof.

[tokumaru]

If I remember well, Bunnyboy seems to be working on an MMC3 clone so that should fix your issue. He barely mentioned it in this one.

The MMC3 still has some annoying limitations, and I wonder if bunnyboy can really get the MMC3 right, since it doesn't work 100% on the PowerPak yet (every now and then someone complains about jumping status bars and such).

[Banshaku]

Maybe but at the least it's a start toward a more interesting mapper. Try to be a little bit more optimistic

[tokumaru]

Maybe but at the least it's a start toward a more interesting mapper. Try to be a little bit more optimistic

Bunnyboy's creations are much more marketed towards pirates (who want to play pirate games on their PowerPaks or make repros) than developers. That's not necessarily a bad thing, because developers alone don't put enough money into this to make it worthwhile for him, so if it weren't for the pirates we wouldn't even see most of these creations.

For that reason, the MMC3 ReproPak will obviously be a commercial success, considering the huge number of commercial games that use it. If actual effort was put into giving better tools to homebrew developers, there could easily be a better mapper than the MMC3 but still with a similar level of complexity.

I guess I'm bitter about this because the scanline counter on the MMC3 doesn't play nice with things I got used to doing on the NES for every project I work on (using 8x16 sprites from the background pattern table), which renders it completely useless for me. The smaller PRG banks and mirroring control alone are not enough for me to want to use it (I'd rather stick to simple discrete logic mappers in this case), all I want is a decent scanline IRQ functionality that doesn't break under several common circumstances.

[Banshaku]

Bunnyboy's creations are much more marketed towards pirates (who want to play pirate games on their PowerPaks or make repros) than developers.
That's not necessarily a bad thing, because developers alone don't put enough money into this to make it worthwhile for him, so if it weren't for the pirates we wouldn't even see most of these creations.

I know but how many good game that use a more advanced mapper have been made yet? Unfortunately, the answer would be none. I know it's again a chicken/egg thing but until we can make something that it worth it, no new mapper will be done. Or unless you can prove that you can deliver and already have a few successful projects under your belt, nobody will invest in any R&D for it. So for now, there's nothing we can do. That MMC3 clone is better than nothing.

Edit:

You updated your message at the same time I was posting this one. For the IRQ, maybe there could be a way to make that MMC3 clone to do more thing? I don't know enough about those hardware thing to know if it's possible or not. For example, to make it MMC3 backward compatible and at the same time make some behavior change if you set certain flags. That would be interesting.

[tokumaru]

For the IRQ, maybe there could be a way to make that MMC3 clone to do more thing? I don't know enough about those hardware thing to know if it's possible or not. For example, to make it MMC3 backward compatible and at the same time make some behavior change if you set certain flags.

If all games used the scanline counter as it was intended to, as long as the IRQ fired at the same time as the original mapper I'm sure it could be implemented in a more solid way that didn't break under the circumstances that the MMC3 does.

I'm not sure if all MMC3 games play by the book though, because I seem to remember that if you break certain MMC3 rules the counter still works in a predictable way, even if different than usual. If some game used one of the alternate ways of scanline counting this idea unfortunately wouldn't work.

[Banshaku]

Maybe the programmers at the time didn't know how the MMC3 worked properly so that's why they seems to have not gone by the book.. I wouldn't be surprised at all.

We always get carried away on someone else topic If we go back to the topic, I think an MMC3 clone, if the price is affordable, would cover the requirements that Sivak asked. It got 8k prg bank switching, up to 256k of CHR-ROM, one pattern table is switchable 1k banks, the other one 2k. Ram can added to it, which is a plus.

I know you said 16k switchable banks but I would go against that. If someday you use any sample in your music, that will complicate things. That 8k fine grained selection seems a better option.

[Bregalad]

We have talked many times about a new mapper for the homebrew community, but there seems to be a chicken vs egg kinda thing going on: nobody wants to program a game for a mapper that doesn't exist and nobody wants to make a mapper for which no games exist.

Well I made up a mapper for which no games exist on my SN-ROM board. It could be seen as a complicated UNROM/BNROM mapper or a simplified MMC1 depending on you look at it. Not all of it's features are confirmed to work anyway, but it works okay at cloning UNROM and SNROM games, but I've had issues with the battery.

Another argument is that with already 100+ mappers arround, it'd be a good idea to use/clone an existing one instead of inventing even more new ones.