Mapper Suggestions

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Mapper Suggestions

Post by Lucradan »

I'm working on an new RPG game for the NES in the style of Final Fantasy / Adventures of Musashi and am looking for suggestions on which would be the best mapper to use. Currently I'm using CHR RAM but I am finding that copying all the tile information from PRG ROM to CHR RAM is a big waste of valuable VBLANK time. I also expect I will be running into other issues down the road when it comes to scrolling on the world / town maps and dialog boxes with NPCs. I'm considering using the MMC5 and am working through the Wiki document (https://wiki.nesdev.com/w/index.php/MMC5), but this is my first delve into mappers usage.

1. How difficult is it to procure a MMC5 mapper in case I wanted to make a cartridge version of the game?
2. The wiki is very good from a technical perspective, but is there a tutorial for creating in-game effects in ASM6 available somewhere?
3. How difficult is it to program the MMC5 Mapper?
4. Do you think the MMC5 Mappers is appropriate for an RPG game?


Here is the title screen for the game and and my 8bit translation of the source art.
26730730_1759085310788890_6617375418762095964_n.jpg
Fu Leng Cutscene.png
User avatar
dougeff
Posts: 3079
Joined: Fri May 08, 2015 7:17 pm

Re: Mapper Suggestions

Post by dougeff »

From INL...
Mapper 5: MMC5 ExROM
A simplified version that supports large memories of MMC5 may be possible
Sounds like...If all you need is extra ROM space, then yes.
in-game effects
what does this mean?

3.MMC5 is the most complicated *Nintendo mapper. If all you are doing is swapping ROM banks, shouldn't be too bad.

4.Lots of mappers would work for an RPG.

*Konami VRC7 might be more complicated, due to unusual audio chip.


EDIT, I personally like CHR-RAM...but if you don't, maybe use MMC3, which is available from INL.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Mapper Suggestions

Post by tokumaru »

The MMC5 is great, it's the most capable mapper ever created, and whatever you've ever seen the NES do can be done with it. Unfortunately, this makes it harder and more expensive to replicate, so support for it in Flash carts is incomplete and nobody has cloned it for use in homebrew releases, so you'll be stuck with hunting donor cartridges if you plan on making cartridges of your game.

The MMC5 is usually overkill, though. The only thing it does that no other mapper can do or simulate is the extended graphics mode (8x8-pixel attributes, 16384 background tiles, 512 tiles for 8x16-pixel sprites), but most NES game designs don't actually need those.

If you need a lot of pattern table animations, CHR-RAM will indeed consume a lot of CPU time, but RPGs don't usually have huge characters or fast camera movements, so there should be a decent chunk of bandwidth free for CHR-RAM animations.

If you really feel like upgrading the mapper and switching to CHR-ROM, the MMC3 is a much safer bet. It has a decent scanline counter (with a few gotchas) for raster effects, mirroring control, reasonably fine CHR bankswitching, easy support for battery backed RAM... everything an RPG might need, and unlike the MMC5, the MMC3 is well supported and has been cloned for homebrews. It's also the most utilized mapper in commercial releases, so there's nothing more "NES-like" than the MMC3.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Mapper Suggestions

Post by FrankenGraphics »

I'm another one to recommend mmc3 (which you can have in either flavour - chr-ram or chr-rom) in that case.

You can add prg-rom up to 8MB if you so wish, ask INL for a price for the amount of prg and chr you need.

If you go with MMC3 with CHR-RAM instead of CHR-ROM, the usual size (today, via INL) is 32kB for that RAM. That ought to be enough to load all graphics you need between areas, instead of loading them continously?

Caveat is that the more complex the mapper (and the larger the memory), the more you need to pay per unit.

GTROM should lend itself well to a text-heavy rpg, btw. You'd have 256 tiles free for non-text and yet another 256 tiles for text, HUD and symbols. You cannot mix them - either needs to be on either side of your sprite 0-triggered screen and chr split. A little back burner project i have (shadowgate-style picture and text adventure) is planned to do precicely this once i've come far enough.


Another important decision is... there's almost a 10$ 8$ difference between these two PCB suggestions, per unit, and increasing if you start to add extras. The question you then need to ask is if the additions mmc3 can deliver is enough to either ask ~10$ ~8$ more of the potential buyer, or if it is worth the increased risk/decreased margin of profit soaking up the cost yourself, or a comprimise between these two.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Mapper Suggestions

Post by tepples »

Is Fantasy Flight Games involved with this adaptation of L5R?
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Mapper Suggestions

Post by FrankenGraphics »

I thought the logo looked familiar!

All i know is they have formed a new(er) digital develoment division recently.
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Mapper Suggestions

Post by Lucradan »

The MMC3 TKROM looks like it gives me a sufficient amount of PRG/CHR ROM and a battery save option.

Ideally I would love something with CHR RAM bank switching and the ability to let the CPU write to the unused CHR RAM banks outside of VBLANK and/or without PPU rendering disabled.

Maybe there is a better solution, but here is the problem I am running into:

The introduction cut scene to my game is graphic intensive. It consists of a 13 pages each with their own text and images (which can't all fit in the same bank). Currently I have all but 2 of them programmed as separate ASM files which I eventually need to merge together into something much more memory efficient. Each page starts with loading loading the background and sprite tiles into CHR RAM. In the first bank, the first 256 bytes (16 tiles) is used for rendering scrollwork and basic blocks. The last 1 KB is used for text (64 glyphs). Everything in between is designated for the images on the screen. I want the user to be able to press a button to move from one page to the next without having the screen go black (the background color). I've brought up this question in this forum before and figured the only way I can pull this off was to use two nametables in PPU; the one being displayed and one being constructed through partial VBLANK writes offscreen. When the user clicks forward (and the next page has been completed), I adjust the scrolling and swap them. This works well for nametables, but I realized I can't do this efficiently because the background tiles also need to be swapped into the CHR RAM between pages. Since I am using both banks (sprites and backgrounds) to get extra color details on the images, I can't figure out how to swap the tiles without forcing a render disable (black screen flash). If I had CHR RAM bank switching that would help. If I had the ability to write to the unused CHR RAM bank outside of VBLANK / Disabled rendering I could do a smooth transition. CHR ROM bankswithing would also allow me to pull this off if I can organize the tiles into 1KB chunks.
Untitled.png
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Mapper Suggestions

Post by Lucradan »

tepples wrote:Is Fantasy Flight Games involved with this adaptation of L5R?
They are not involved with development, but are very much aware.
FrankenGraphics wrote:I thought the logo looked familiar! All i know is they have formed a new(er) digital develoment division recently.
As long as I stay on the NES medium and get IP permissions for any kickstarter release they have claimed no conflict.

If that changes, I will adapt.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper Suggestions

Post by lidnariq »

Lucradan wrote:Ideally I would love something with CHR RAM bank switching and the ability to let the CPU write to the unused CHR RAM banks outside of VBLANK and/or without PPU rendering disabled.
Yeah, that's basically just not happening. Balancing your very limited vblank time is part of what makes the NES the NES.

While the MMC5 does support a dual-ported RAM for the 1 KiB of RAM inside the MMC5 itself, it can only be used as one of the nametables, so you can't update multiple nametables that way. And no other existing mappers do.

While you could use modern advanced hardware to increase the amount of dual-ported RAM, it's inauthentic....


And given your specific problem, it's also unnecessary, once you have bankswitched CHR RAM.
User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2064
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Mapper Suggestions

Post by FrankenGraphics »

[They] are very much aware. [...] As long as I stay on the NES medium and get IP permissions for any kickstarter release they have claimed no conflict.
That's pretty cool of them! :beer:
User avatar
Lucradan
Posts: 101
Joined: Wed Sep 21, 2016 12:08 pm

Re: Mapper Suggestions

Post by Lucradan »

lidnariq wrote: Yeah, that's basically just not happening. Balancing your very limited vblank time is part of what makes the NES the NES.
Didn't figure as much but I don't know enough about all the advanced mappers to know better. Hence why I wrote the post.

I think I can do all the CHRRAM writes in VBLANK in pieces, swapping between the sprite/background banks between each page. I was just looking for an easier route.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mapper Suggestions

Post by lidnariq »

Use multiple pages of CHR RAM, upload everything ahead of time, and swap out banks as you scroll. MMC3 gives you fine enough control that you could divide the screen into 88-pixel-wide zones, such that only three would be on-screen at one point and the 4th bank of tiles can be swapped at that point.

Actually, that would work fine with CHR ROM too.
FrankWDoom
Posts: 260
Joined: Mon Jan 23, 2012 11:27 pm

Re: Mapper Suggestions

Post by FrankWDoom »

for reference, the two titles you listed are both mmc1, as are all the dragon warrior and ultima games. both chr-ram and chr-rom are common in NES carts, with rpgs tending to use chr-ram. battery backed save ram is also common. the major drawback is the lack of an IRQ. mapper writes are a little more work and you should copy the boot code into every bank just be safe, since the last bank isn't fixed, but plenty of games worked within those limitations.

a newer alternative is UNROM-512 https://wiki.nesdev.com/w/index.php/UNROM_512
it's a homebrew board that supports banked chr-ram, which you could use to cut down on write time during action. it also supports saving by way of self-flashing rom, rather than battery backed ram. again there's no IRQ, and you're limited to guys selling new boards if you want actual hardware to work on.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Mapper Suggestions

Post by Bregalad »

Lucradan wrote: 1. How difficult is it to procure a MMC5 mapper in case I wanted to make a cartridge version of the game?
To be honest, very difficult. Basically you'd need to butcher existing MMC5 games (bad !) or do some advanced FPGA design.
2. The wiki is very good from a technical perspective, but is there a tutorial for creating in-game effects in ASM6 available somewhere?
No. ASM6 is an assembler, it is designed for coding and has nothing to do with in-game effects which are done by means of graphics, and graphics editors such as YY-CHR.
3. How difficult is it to program the MMC5 Mapper?
The initialization is a bit complex as many registers should be written to, but for the rest it's easier than other mappers as there are more feature, and the scanline counter is much easier to work with than MMC3's.
4. Do you think the MMC5 Mappers is appropriate for an RPG game?
Yes it is appropriate, however it's likely to be overkill, and it'll be a hinderence in the case you want to actually produce the game. MMC1 and MMC3 can be simulated using relatively simple CPLDs, MMC1 can even be simulated with 4 PAL22V10 chips or 2 ATF750C chips. On the other hand MMC5 is likely to require a FPGA (unless you restrict to some features of the mapper, such as Castelvania 3), and as such, developing for it is harder.

So I'd say if you indeed plan to use MMC5 features such as single-tile granularity attributes or extra sound, go ahead, but if you just want to make a NES RPG, it's better to stay to common mappers.
User avatar
MottZilla
Posts: 2837
Joined: Wed Dec 06, 2006 8:18 pm

Re: Mapper Suggestions

Post by MottZilla »

Lucradan wrote: The introduction cut scene to my game is graphic intensive. It consists of a 13 pages each with their own text and images (which can't all fit in the same bank). Currently I have all but 2 of them programmed as separate ASM files which I eventually need to merge together into something much more memory efficient. Each page starts with loading loading the background and sprite tiles into CHR RAM. In the first bank, the first 256 bytes (16 tiles) is used for rendering scrollwork and basic blocks. The last 1 KB is used for text (64 glyphs). Everything in between is designated for the images on the screen. I want the user to be able to press a button to move from one page to the next without having the screen go black (the background color). I've brought up this question in this forum before and figured the only way I can pull this off was to use two nametables in PPU; the one being displayed and one being constructed through partial VBLANK writes offscreen. When the user clicks forward (and the next page has been completed), I adjust the scrolling and swap them. This works well for nametables, but I realized I can't do this efficiently because the background tiles also need to be swapped into the CHR RAM between pages. Since I am using both banks (sprites and backgrounds) to get extra color details on the images, I can't figure out how to swap the tiles without forcing a render disable (black screen flash). If I had CHR RAM bank switching that would help. If I had the ability to write to the unused CHR RAM bank outside of VBLANK / Disabled rendering I could do a smooth transition. CHR ROM bankswithing would also allow me to pull this off if I can organize the tiles into 1KB chunks.
You don't have to black out the screen to upload CHR Patterns or update NameTables. You just need to hide it from the player. If you need to upload new graphics for the page, you could fade out or otherwise do an effect to dissolve the graphics from view and then update those patterns without the user seeing it over the course of several frames. For the text you could have a palette that you set all the text to make it invisible as you change it, if you have a spare background palette. But it sounds like your main issue is the graphics and switching them. So again I'd suggest when changing pages just do some effect to dissolve the image so it is no longer on screen and then update the patterns so you have the ones for the next page. If you really needed it to be instant then you need bank switching for CHR.
Post Reply