I think if you keep certain constraints in mind, you can start with MMC5 for ease of development, and if if/when the game is completed and it turns out that the game doesn't utilize the mapper fully, you can convert it to another, simpler mapper (e.g. one with CHR-RAM). If it's only the big CHR-ROM that you're after, such conversion should be fairly simple (depends on how many of the other MMC5 features are used, of course).

Yeah, when reading all these comments, that's what I've been thinking. Writing this type of game, how the background is scrolled and updated sounds like the absolute simplest part of the whole project, I'm sure that part of the game engine could be converted, if needed. Handling the AI and all those sprites, making it fun to play, sounds like the challenging part. I don't even like football, but I've played the hell out of Tecmo Bowl and TSB.

Anyways, if it can't be played on an NES cart easily, big deal, it's not like this type of game could safely have some kind of big commercial release as it is. With the massive amount of licensing involved, plus EA still has exclusive rights for making any NFL games (lame!). I've seen plenty of Tecmo Super Bowl hacks being sold apparently without a problem, but I have a feeling that's only because it's Tecmo's game and they haven't bothered to complain about it. A totally new game however, could be in new territory.

The reason I am dead set on MMC5 is because of the huge CHR ROM, huge PRG ROM (great for sound samples), 16384 bg tiles available simultaneously (allows for first down/line of scrimmage, referees, etc. while keeping sprites free for the players), and certainly the individual attributes per background tile. The end zones and midfield logos are strategically sized and placed so that each is vibrant with almost no compromises (except teams like the Titans, Ravens, Redskins to name a few) and this would be heavily compromised by any other mapper. Again, not worried about playing it on an actual cartridge for now because it's a long way from complete and I haven't given up hope that someday, somewhere, someone will figure out how to print some flash MMC5 cartridges. The goal of this one is best quality + fewest compromises.

I've run into a technical problem that I can't diagnose and I'm sure you will spot quickly. All this version of the game can do so far is scroll left/right and switch back and forth to a rudimentary menu by pressing start. On initialization, the field looks fine. Switching to the menu, the menu is doing as I expected (didn't change the attributes yet) but when switching back to the field I get some random garbled crap. The obvious reason would be that writes to the PPU are taking place outside VBlank but what I can't figure out is why the garbling doesn't happen on initialization and why it does when I return to the field from the menu.

I tried experimenting with the placement of my $2000 and $2001 writes, namely turning NMI off/on and rending background off/on in strategic locations. I tried to sprinkle in a VBlankWait in there and still nothing. Any suggestions?

I imagine it wouldn't even be compromised at all. Although more difficult to implement, we talked about how this could work on other mappers (like swapping out graphics down the field). A football game simply just isn't that taxing graphically.

In the DrawField routine, it looks like you jsr to PPUoff, clear the nametables, jsr to PPUon, then write the data to the nametables. So maybe the screen is rendering while being written? In any case, I tried it on Nintendulator and the field always shows up corrupted, coming back from the menu or not, until you scroll it off the screen. And the corruption is different when you do a soft reset instead of a hard reset.

Isn't the MMC5 ExRAM weird in that it needs to be written to DURING RENDERING, the exact opposite of regular VRAM?

Yeah that's what I've heard, the code I was looking at was writing to $2007 though. Then it writes to ExRAM after that. Screen was already on, after the writes it turned the screen on again, which made me think it might have been a mistake.

Also, looking at it again, it looks like it doesn't wait for the PPU warm-up. You should have two LDA $2002 / BPL - loops soon after reset. I don't know if that's something that usually emulated, but could be the problem maybe?

I'm just not sure. I tried adding a few JSR VBlankWait 's in there right after the reset code and it didn't seem to do much. Also, I tried breaking up into smaller chunks the looping code in DrawField that draws the black tiles on top so that writes entirely take place in VBlank, but that didn't work. I also tried to make any writes to $2000 and $2001 take place only in VBlank but that didn't help. I've been trying to diagnose this problem for days!

The vblank wait code appropriate before the PPU has warmed up differs from the vblank wait code appropriate after the PPU has warmed up. Before the PPU has warmed up, you want to spin on bit 7 of $2002. After the PPU has warmed up, you want to enable NMI and then wait for the NMI handler to set a variable.

OK I fixed most of the problem from your suggestions. I've tried experimenting with placements of the JSR NMIwait to get rid of the quick temporary glitchy screen when transitioning between field and menu - with no luck. I thought I would just turn the PPU rendering off before completely filling the screen with new background tiles and then turn it back on when done but I'm still getting a quick temporary glitch. How's it really supposed to be done? You can see what I mean when you run the game in slow motion.

Yeah, usually you wait for vblank, turn the screen off, wait for vblank, turn the screen on. Just noticed PPU_On is called just before you call DrawField. That must be it, screen is on while waiting for that first vblank.

There's something else weird. The field shows up in FCEUX, but FCEU and Nintendulator just shows a solid green screen. Nestopia says it's a corrupt file and doesn't run it. NESten says the "ROM image is smaller than required", then crashes.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum