Mapper choice for football game?

I'm currently in the early stages of programming an NFL football game. I plan to make a better version of Tecmo Super Bowl that modernizes the game and includes better graphics, gameplay, and options. As it stands, I am using MMC3 mapper 004. I am looking for the best mapper for this project, preferably one that incorporates CHR RAM which I have never used before. I see that TQROM mapper 119 has both CHR ROM and CHR RAM but only 128 PRG and 64 CHR. This will not be enough. I will need something close to 128 KiB for field graphics alone. I want CHR RAM so I can animate players more smoothly and create pixel-by-pixel tile effects on objects like the flags that hang on the goal posts.

What mapper would you suggest? Should I consider MMC5 or MMC6?

You could use TGROM (Mega Man 4, Mega Man 6, Ninja Crusaders), or a TLROM board modded to behave like TGROM. Or you could use TGROM modded to take a 62256 (32 KiB SRAM), which allows both tile animation and arbitrary updating.

But what in your project needs MMC3? Could it get away with something simpler like BNROM (Deadly Towers, Haunted Halloween '85) or MMC1 SGROM/SNROM (too many to list)?

There are a bunch of pirate knockoffs of MMC3 with CHR-RAM and CHR-ROM, supporting 2KiB to 4 KiB CHR RAM and 128 to 254 KiB CHR ROM. (Mappers 74, 191, 192, 194, 195)

For manufacturability, I think the best option is to just use a large CHR-RAM (128KiB ones are easily purchased currently) and upload all the graphic data from PRG-ROM instead.

Note that if emulator compatibility is an objective, that will preclude anything not explicitly in this list.

If you're not going to use scanline IRQs, even the MMC3 is probably overkill. Which of the MMC3's features are you planning on using, and for what purposes?


Why do you need over 8,000 tiles to draw football fields? I also don't see why you'd need CHR-ROM + CHR-RAM. Isn't it just a football field (which I can't imagine using more than 256 tiles) with a few animated tiles, plus the animated players as sprites?

Perhaps the team logos in the end zones take a lot of tiles.

Too address both questions: Part of my revision of Tecmo Super Bowl involves creating every team's two endzones, a mid-field logo, logos on the field, NFL Play 60 and so forth. The two endzones and the midfield graphics combine to 4K per team. So for all 32 teams that is 128K of data best suited for CHR ROM. I want each tile to be drawn separately for each football player with help from CHR RAM to allow more animations to run at the same time. These fields will look great. Lastly, I want to add a few finishing touches that only can be done with CHR RAM.

They do. They're worth it. Makes the game more NFL. I'm hoping there is a solution out there where I can have a bunch of CHR ROM and a large PRG ROM but still have the ability to create new tiles down to the pixel with help from CHR RAM.

Will you be switching large portions of CHR during gameplay, though? If not, it makes much more sense to upload the field graphics to CHR-RAM when each game starts than to use something as unconventional as CHR-ROM + CHR-RAM. And you can also animate small background elements the same way you animate the players.

EA WILL SUE


If only the left end zone or the right end zone can be seen at once, it makes sense to bankswitch out the tiles for the one that isn't showing if at all possible.

Yes, that would work better with CHR-ROM (or more than 8KB of CHR-RAM) if the field really needed that much detail, but according to him, "the two endzones and the midfield graphics combine to 4K per team", so I'm guessing the field doesn't need any bankswitching during gameplay, in which case a simpler mapper might be the way to go.

I have 1K dedicated to field graphics common to all fields.
I have 1K for text and a field goal post of one side of the field
I have 2K for a single endzone.

CHR ROM is good for the bank switching midfield. I think I could live without CHR RAM if I had enough CHR ROM. I am looking more closely at mapper 005 MMC5.
http://wiki.nesdev.com/w/index.php/MMC5
One thing I think I'm understanding is that you can access 16384 tiles at once (256x64) with MMC5. I'm only familiar with MMC3 so this is unfamiliar to me as to how that works. I like that is says that the max capacity is 1024 PRG ROM and 1024 CHR ROM but I still need to figure out to how to get it going.

The vertical split screen could come in handy too.

One of the problems with the MMC5 (the NES super mapper, yay!) is that it's not currently available for making new carts. AFAIK, the only way is still to use donor cartridges. The other problem is the lack of full support for it in Flash carts.


It has an extra 1KB of internal RAM, which may be used to extend the information contained in the name tables, where each entry is 8 bits and can only address 256 tiles. The extra bits allow you to address 16384 tiles, and select one of the 4 palettes for each tile, as opposed to each 16x16-pixel area like it is with the attribute tables.


I think that the 1MB of CHR RAM is divided into 4 banks of 256KB, but I didn't look it up.


I don't think any games ever used this...

How wide in pixels is the space between the end zone and the center logo, how fast in pixels per second (pixels per 60 frames) can a player run, how big are the players in tiles, how many are there if not 22, and how fast in frames per second do you plan on updating the players' cels? I need this information to assess your video memory bandwidth requirement in order to determine whether it'd be practical to load the left end zone, center logo, or right end zone in the background as a player approaches it. My last couple major NES projects (RHDE: Furniture Fight and Haunted: Halloween '85) had plenty of dynamic CHR RAM updates, and I wonder if that strategy would be good enough for your project.

You have 8 pixels per horizontal yard, just as in my Mode 7 field mock-up, which means the distance from goal to the 50 yard line is 400 pixels. From this you must subtract 256 pixels (the width of the screen) and half the width of the center logo, and then divide by the player's maximum running speed to see how many frames you have to get the tiles replaced. You can comfortably replace 8 tiles per vblank, or a full 128 tiles in a quarter second provided nothing else is uploading tile animations. Can I assume the screen won't scroll faster than 10 yards per second, or 8 pixels per 6 frames?

If that's not fast enough, there's always the option of replacing the 6264 SRAM in a TGROM or compatible board with a 62256 SRAM, which gives you 32K of bankable CHR RAM. Emulators that support NES 2.0 should handle it without problem.

I think it is safe to say my screen will never need to scroll more than 8 pixels per 6 frames. I haven't thought of all the possibilities yet of how I want to update the PPU. There is at least one full screen of space after the endzone fully comes off screen to when the midfield logo appears so CHR ROM is great for this because of the bank switching but not totally necessary. The more I think of it, the better it sounds to have 16384 tiles at my disposal at all times (MMC5). If I have 1024K CHR ROM, which 16384 tiles do I have access to? Is that dictated by my write to $5130? Is that what they mean when it is written regarding $5130:
"When the MMC5 is using 2KB/1KB CHR banks, only 512KB/256KB of CHR ROM can be selected using the previous registers. To access all 1024KB in those modes, first write the upper bit(s) to register $5130 and then write the lower bits to $5120-$512B. When the Extended RAM mode is set to 1, this selects which 256KB of CHR ROM is to be used for all background tiles on the screen."

So if you can't sell the game and the existing Flash carts don't have good support for the MMC5, are people stuck with running it on emulators unless they decide to build a cart themselves from an MMC5 donor?


Yes, that seems correct. There's no "master banking" like I thought there was, so you can freely mix and match tiles from all 1024 banks.


Well, then $5130 starts to act as a master bank selection register. It selects which group of 16384 tiles will be used, and you can't mix tiles from different groups. I'm not sure how that affects sprites, though...

INL offers a partial MMC5 mapper, currently. I'm not sure which parts that includes. If you talked to him you might be able to work out whether the subset you need can be supported by it.

Though, to tell you the truth, the more somebody asks about MMC5, the less likely I think they are ever going to finish an NES game.

I think almost everyone that gets started on NES development becomes fascinated with the MMC5. We have tons of topics where people ask "Is this, this and that possible?" with answers like "Yes, if you use the MMC5", so this is only natural. I know I really wanted to use the MMC5 at one point.

My opinions about mappers changed a lot as time passed. Being obsessed about complexity didn't get me anywhere, and the more I'm able to simplify things, the closer I think I am to reaching my goals. Aiming for simplicity doesn't necessarily mean dumbing things down or giving up features though, it's more about asking yourself questions like "do I really need this?" or "is this the best way to do this task?". Sometimes we assume that one particular path is the way to go, and the stubbornness to remain on that path prevents us from making as much real progress as we'd like.

I started making a game for the MMC3, which is what a lot of iconic NES games use, but now I'm fairly happy with the incredibly simple BNROM mapper. In retrospective, the only significant thing I had to give up was the scanline counter, which was only really necessary for a couple of non-essential visual effects, which weren't really worth the complications of using a more advanced mapper. I can still have some of these effects, using sprite 0 hits, sprite overflows and timed code, so I got over that pretty quickly. Everything else from the previous design is intact, even if implemented a little differently.

I simplified things a lot on the engine side too... Previously I believed that I'd only be able to max out the VRAM update capabilities of the NES if I used dedicated NMI handlers and update routines, but recently I was able to come up with a very optimized general VRAM update method, which can be used for the entire game. I literally replaced 20 subroutines with a single one, which is slightly more complex than the average subroutine it replaced, but still, it does the job of 20!

It frustrates me a bit that I was never able to accomplish anything significant in the field of NES development, so hopefully this new line of thinking will get me somewhere sooner. I am making progress faster than I used to, and what I'm creating does feel more robust and stable, so those are good signs.

There are four sets of tiles:

1. Left end zone
2. Right end zone
3. Midfield logo
4. Field graphics that are not left end zone, right end zone, or midfield logo, such as lines and yard numbering

Sets a-c fill 4K, leaving no room for d unless a, b, and c are swapped in on demand.

Actually, the NFL will.

They're astoundingly aggressive about protecting their trademarks, which includes all the team names as well as all the logos.

They might not care in the case of a single non-reproduced homebrew, but if you ever want to sell it that won't go well.

I think it's pretty clear that OP is unconcerned with the NFL trademark issue.

They've already been doing it for years at: http://tecmobowl.org/

You are correct but I am going to see how MMC5 treats me and I think that makes my task simpler. I understand that there is an art to simplicity but the point of me making this football game is to have no expense spared on making it the best NFL game playable on an NES. It will likely take years to develop so I'm not in a rush to put in on a cart.

I am converting my MMC3 to MMC5 and I figured out bank switching but not sure how I write one of the 16384 tiles to the nametable. After that is figured out, I think I'm off to the races.

I always wondered how the Tecmo fans could legally sell Tecmo Super Bowl carts with updated rosters. They've been doing it for years.

I have been experimenting and I still can't figure out how to write to a nametable using MMC5. I successfully bank switched tiles and got my palettes in order with writes to PPU $3F00 but I don't know how to write to a nametable. Since MMC5 allows me to pick any tile from a 256K super bank, then I must have to make an additional write somewhere because writing a single value to $2007 won't be enough. What do I do?

I attached my program so you can see what I have so far. Maybe that will help.

The answer is simple: they haven't. They have, however, been selling them illegally, which is often very easy to do.

Because nobody has notified Tecmo Koei, NFL, and NFL's present exclusive licensee EA.

Yet.

The MMC5 has 1KB of RAM mapped at $5C00-$5FFF, which is where the extended attributes go. The lower 8 bits go to the name table as usual ($2006/$2007 writes), but the expansion RAM can be addressed by the CPU directly. You also have to select the proper extended RAM mode (mode 1) through register $5104. Note that in this mode, according to the wiki, the extended RAM can only be written to during rendering, which is the opposite of regular VRAM, which can only be written to during vblank. Go figure.

Anyway, each byte there will provide 6 more tile index bits (for a total of 14 bits, allowing access to 16384 tiles) and 2 palette bits, allowing each tile to be colored individually.

Another important point is that since there are only 1024 bytes of expansion RAM, and each name table is 32 x 30 = 960 bytes long, the MMC5 doesn't have enough memory to extend the attributes of both name tables individually, so the same extended attributes are used for both name tables. You have to take this into account when scrolling.

I'll experiment with that to see if I can get it going. From what I'm reading here...
"The MMC5 has an 8-bit incrementing IRQ counter that watches the PPU as it renders, and counts each passing scanline. When the counter reaches the desired IRQ scanline (specified by the $5203 register), it signals an IRQ. It also uses an In Frame signal which can be read from $5204.6 in conjunction with the 8-bit counter. Games can use this signal as an indication of whether or not the PPU is currently in rendering time."
Regarding $5204:
When set, the "In Frame" signal specifies that the PPU is currently rendering a scanline. It also plays a role in how IRQs are generated.
The IRQ Pending flag may be raised even if IRQs are disabled.
Any time this register is read, the IRQ Pending flag is cleared (acknowledging the IRQ).

I think it's nice that the mapper provides a way for you to tell whether the PPU is rendering or not, but that's not what worries me about the extended attribute mode, since there are other ways to detect the start of rendering. It's that you're changing the data as it's being used to render the picture that bothers me. If you need to update a column of tiles that spans the whole height of the screen, there's no safe time to do it so you avoid seeing half old data and half new data on the screen. You probably need a status bar or something of the sort to divide your screen in different areas, so that when one area is being rendered, you're updating the other.

My program will have a status bar at the top of the screen. I still can't seem to figure out what code is needed to detect rendering. This is what I thought:


After it exits the loop, then rendering has just begun. $5203 is not mentioned in my code. After the loop is exited, I begin my writes to the extended RAM. Still, my nametable is turning out to be a jarbled mess.

You know, but speaking of row scrolling for a status bar, does anyone know of any NES games that scroll the BG every line at different speeds for a SF2-esque floor? That would look great for a football field, the field goal would have to be made out of sprites though. I assume raster splits are difficult on the NES due to the lack of HDMA or a scroll table? I always seem to hear about "sprite 0 hit".

Here's Rad Racer after a crash:



Here's Rad Racer generally: https://youtu.be/sVSCFf6BjQ4?t=2m47s

How hard it is to do a lot of splits like that depends on the mapper.

The worst part is that I own Rad Racer...

Typically most 3-D racing games did that. They mostly rely on fixed cycle loops after the 1st split I suppose.

Personally, though, I find Tobidase Daisakusen/3-D Worldrunner even more advanced than the later Highway Star/Rad Racer(and even better than JJ, the sequel to Tobidase Daisakusen, which was exactly the same game with 3-D goggle support, but lacked the ability to walk back, and much to the 8-bit versions of Space Harrier, which it obviously took "inspirations" from). They're programmed by the same guy though, who also programmed all the Famicom Final Fantasy titles.

https://youtu.be/bukusPiWTmU?t=435
(not every line, but I like how it looks)

If you want a high level breakdown of what Rad Racer is doing, I wrote one a long while back:
http://forums.nesdev.com/viewtopic.php?t=8588

It's only using MMC1. The only special mapper capability involved in the effect is being able to switch between horizontal and vertical mirroring.

I want to say Battletoads vs. Double Dragon, but I'm not sure.

That's what I posted earlier, I guess I should've include the game name in the post.

Oh, I was out when I posted that, and I can't watch videos on my data plan!

Still can't figure out how to properly select the proper tiles to place in the nametable for MMC5. I am hoping to use the extended RAM so that I can select from any of the 16384 tiles plus having custom attributes for each individual tile. I tried doing writes to the nametable at the beginning of VBlank as usual, and then doing writes to the extended RAM at the beginning of rendering (as the MMC5 instructions suggest) right after, but no luck. Here is a copy of my code, which is built to compile with NESASM3. I must be missing something about how this is supposed to be done. Do I have to write to the extended RAM first and then write to the nametable with $2006/$2007?

What am I doing wrong? Notice my nametable is all screwed up and using the hex editor in FCEUX, I see the writes to $5C00-$5FFF are not right.

I don't know if this is the problem, but you appear to be misdetecting the start of rendering.


Why are you using an addition to check the state of one bit? Aren't you supposed to use AND, or even this:


...since BIT copies bit 6 to the overflow flag?

I believe TMNT Tournament Fighters uses the effect as well.
https://www.youtube.com/watch?v=NDHPelJ-Mow