Mapping Help - MMC 1

[Disch]

I always had two paticular beefs with MMC3:

1) No 1-screen mirroring (seriously, wtf)

2) restrictive and coarse scanline counter instead of a flexible, fine-tune, and unrestrictive CPU cycle counter.


When you compare MMC3 to any one of the several 2nd party mappers which have similar functionality (VRC4, FME7, VRC6, whatever mapper 18 is), they all pretty much leave MMC3 completely in the dust in terms of functionality (even if they are a bit more weird to use). Just kind of seems pathetic to me that MMC3 was the worst option in its class.

I still like MMC3 over MMC1, though, if only because it has an IRQ counter. MMC3's lack of 1-screen still makes MMC1 have some function, though.

Of course... if they would have just PUT decent IRQ functionality on the NES from the get-go instead of putting it into mappers, most of this would be a non-issue. I still don't understand why they put APU Frame IRQ functionality in, but decided not to make Sprite-0 hit generate an IRQ. durrrrr. They even had the presence of mind to put a CPU cycle counter on the FDS and that wasn't released too long after the FC was. I guess they realized that they made a huge blunder pretty quick.


EDIT

Just read your post in more detail doynax. That trick shouldn't work! Writes that are too close together (ie, consecutive cycles) are too quick for the MMC1 to respond. A game which relies on this behavior is Bill & Ted's Excellent Video Game Adventure. The game does "INC $FFFF" where $FFFF=FF to reset the mapper (since this writes FF, then 00). However, the 00 write goes ignored as if it never happened. I would figure the same thing would happen with your trick -- only the first of the two writes would actually happen, and the second would be dropped.

Did you try this trick on an actual board? (read: PowerPak doesn't count). I don't see how it would work unless there's something about the reset bit that makes it take longer to respond... or unless there's different MMC1 versions. Either way, I'd highly recommend you don't use this trick.

[Bregalad]

Writes that are too close together (ie, consecutive cycles) are too quick for the MMC1 to respond. A game which relies on this behavior is Bill & Ted's Excellent Video Game Adventure. The game does "INC $FFFF" where $FFFF=FF to reset the mapper (since this writes FF, then 00). However, the 00 write goes ignored as if it never happened. I would figure the same thing would happen with your trick -- only the first of the two writes would actually happen, and the second would be dropped.

Well, technically the MMC1 takes writes according to the status of the adress/control bus regardless of how many instruction it took to write. Maybe it's the reset signal that makes it not accept writes for a few cycles ? Anyway, like you said, this should be tested on hardware.

I always had two paticular beefs with MMC3:

1) No 1-screen mirroring (seriously, wtf)

2) restrictive and coarse scanline counter instead of a flexible, fine-tune, and unrestrictive CPU cycle counter.

I couldn't agree more, altrough 1-screen mirroring can be possible my chaging mapper from 4 to 118 by then you're limited in your CHRROM bank switches if you use all available 256 KB.

Of course... if they would have just PUT decent IRQ functionality on the NES from the get-go instead of putting it into mappers, most of this would be a non-issue. I still don't understand why they put APU Frame IRQ functionality in, but decided not to make Sprite-0 hit generate an IRQ. durrrrr. They even had the presence of mind to put a CPU cycle counter on the FDS and that wasn't released too long after the FC was. I guess they realized that they made a huge blunder pretty quick.

Yeah, replaceing sprite-zero hit and all that crap by a reliable PPU driven interupt source would be much better (like the SNES and most other console does). However, the good side of this is that it give us fun headaches how to do tricky raster effects, that would be too easy to do otherwise.

[doynax]

Just read your post in more detail doynax. That trick shouldn't work! Writes that are too close together (ie, consecutive cycles) are too quick for the MMC1 to respond. A game which relies on this behavior is Bill & Ted's Excellent Video Game Adventure. The game does "INC $FFFF" where $FFFF=FF to reset the mapper (since this writes FF, then 00). However, the 00 write goes ignored as if it never happened. I would figure the same thing would happen with your trick -- only the first of the two writes would actually happen, and the second would be dropped.

Did you try this trick on an actual board? (read: PowerPak doesn't count). I don't see how it would work unless there's something about the reset bit that makes it take longer to respond... or unless there's different MMC1 versions. Either way, I'd highly recommend you don't use this trick.

Dammit.. No I don't have anything resembling proper hardware to test on.
Then how long do I have to wait between writes to be safe?

[tokumaru]

Personally, I don't like the MMC1 because:

1. the way the registers are written to is weird and slow;
2. 4KB CHR-ROM switching is not good for gaphically complex games;

So I feel that it works much better with CHR-RAM, but then there really isn't an advantage over using UOROM (except for the 32KB PRG switching, which I don't think is very useful anyway), which is simplicity at it's best.

My problems with the MMC3 are:

1. the scanline counter is very limiting, in a sense that in order to use it you must give up on using native features of the system;
2. the way in which the pattern table is divided, they really should have gone for 8 1KB chunks;

In the end, difficulty of reproducing carts aside, I'd rather use the MMC3. The possibility of switching 2 8KB PRG-ROM banks is really necessary in games with a lot of data. The CHR switching is good enough for most games, even if you have some redundancy of tiles.

Usually my game designs involve the use of 8x16 sprites fetched from both sides of the pattern table, so I really do hate it's scanline counter with all my guts. In my current project, I'm only using the scanline counter to hide scrolling glitches by the top of the screen, but as soon as the IRQ fires I start breaking the MMC3 rules.

[Bregalad]

So I feel that it works much better with CHR-RAM, but then there really isn't an advantage over using UOROM (except for the 32KB PRG switching, which I don't think is very useful anyway), which is simplicity at it's best.

The advantage is the official support of SRAM (altrough mapper 2 can also have SRAM there is no official cartridge with it), and the ability to switch between 4 different mirroring modes, which is great and the MMC3 cannot do unless you wire it differently as in mapper 108.

2. 4KB CHR-ROM switching is not good for gaphically complex games;

I don't know what you mean by "graphically complex". 4 KB switching worked wonder for a couple of games like Double Dragon or Fire Emblem, and should work fine in most games, while I'll admit it can be bothersome to mirror the hero sprite and textbox tiles in all sprite and BG banks respectively.

[tepples]

So I feel that [the MMC1] works much better with CHR-RAM, but then there really isn't an advantage over using UOROM (except for the 32KB PRG switching, which I don't think is very useful anyway)

The advantages of SNROM over UOROM are 1. PRG RAM, and 2. battery-backed PRG RAM. Not all games that last longer than a half hour can serialize their state to a 16-character string.

[MottZilla]

We just need someone to clone the MMC5 and put it all to rest with new MMC5 boards. :p at first I thought the MMC5 was crazy, but after working on adding partial emulation of it for my emulator to run CV3, I realized the MMC5 is quite nice. Has the scanline counter that actually works, has the ability to swap in all sorts of ways. Even has the ability for you to have 8KB of Sprites instead of 4K. You can get that extra name table, you can do OneScreen mirroring... there's nothing I can think of that you can't do...

MMC5 I think would even be useful for making a hacked FDS Bios to run FDS games since you can map up to 64K of WRAM in any bank but the last one. I think you could make a hacked FDS bios and just bank ROM in an available (not being loaded) window and load PRG-RAM and then bank back to all WRAM banks for 6000 - DFFF.

All the thinking about MMC5 makes me wish the PowerPAK had MMC5 support now. ='(

Do you think there is any hope that someone might either clone or make their own MMC3 level mapper for repro/new boards like the MMC1 has? While a MMC3 clone would be nice for building games that use it, just a mapper that is similar for homebrew would be sweet. 8K PRG banks, 1K CHR banks, working IRQ scanline counter and support for PRG-RAM. I'd think the hardest part is implementing the scanline counter. Can't be too hard to do this since the PowerPAK FPGA was configured to do it.

[kyuusaku]

We just need someone to clone the MMC5

But it will take a FPGA (nonvolitile/static such as what's used in modchips) to synthesize MMC5 (since Mask ASIC are out of the question). Do you think a homebrew MMC5 is worth the $10 or so more than the cost of a CPLD? Personally I don't.

I realized the MMC5 is quite nice. Has the scanline counter that actually works

How is the scanline counter any different than a MMC3s? I assumed it worked on the same A12 counting principle, unless it counts Phi2 cycles and is triggered on filtered A12 to allow more flexible setup.

there's nothing I can think of that you can't do...

But it comes at a high cost, both to the board maker and customer (and think of all the wasted logic for vastly underused functions)

Do you think there is any hope that someone might either clone or make their own MMC3 level mapper for repro/new boards like the MMC1 has?

Not really because of the flip flop requirement, MMC3 can fit only into the largest 95th percentile of CPLD, much less better mappers which have full 1K CHR switching and a Phi2 counter.

While a MMC3 clone would be nice for building games that use it, just a mapper that is similar for homebrew would be sweet. 8K PRG banks, 1K CHR banks, working IRQ scanline counter and support for PRG-RAM. I'd think the hardest part is implementing the scanline counter. Can't be too hard to do this since the PowerPAK FPGA was configured to do it.

Well the PowerPak is having lots of trouble with the scanline counter probably because the proper logic doesn't work right for some reason. Artoh's FunkyFlash MMC3 however works great using a CPLD, but you'll have to find an EXTREMELY expensive CPLD to fit full 1K switching, which brings us back to using a static FPGA. The best compromise I think would be to use a common smaller CPLD as well as 4x74670 (4x4 bit registers) to form the 8x8 register ;)

[never-obsolete]

How is the scanline counter any different than a MMC3s? I assumed it worked on the same A12 counting principle, unless it counts Phi2 cycles and is triggered on filtered A12 to allow more flexible setup.

from a programmers point of view,

mmc3: the irq is fired relative to the current scanline
mmc5: the value written is the actual scanline#

the whole relative thing is only if you have multiple irqs per frame or setting up an irq mid-frame, otherwise you don't need to worry about it. the mmc3 just forces you to think a little more.

not sure about the hardware differences tough.

[Disch]

How is the scanline counter any different than a MMC3s? I assumed it worked on the same A12 counting principle, unless it counts Phi2 cycles and is triggered on filtered A12 to allow more flexible setup.

I can't say with 100% certainty, but I really don't see how watching A12 would work. Keep in mind the MMC5 syncs with the PPU in other ways besides scanline counting (splitting the screen requires it to know specifically which tile is being fetched... something A12 gives no indication of). Plus, watching A12 would fail utterly if BG and sprites both use the same side of the nametable -- something I'm quite sure MMC5's scanline counter is quite capable of (unlike MMC3).

I find it much more likely that it watches A13 to know when tile fetches occur, and syncs to the scanline some other way.

The big difference from a nesdever standpoint is that MMC3 limits your sprite CHR usage -- sprites can only use 256 tiles if you want the scanline counter to work. But on MMC5 you can use all 512.

[tokumaru]

Do you think a homebrew MMC5 is worth the $10 or so more than the cost of a CPLD? Personally I don't.

Can't say that without seeing the MMC5 game first. We have yet to see such a complex homebrew that requires the features of the MMC5, but if it does happen, it will probably be a good game. Nobody would be crazy enough to make a crappy game for the MMC5 just for the heck of it. The person who does it will probably know what they are doing.

[Disch]

Nobody would be crazy enough to make a crappy game for the MMC5 just for the heck of it.

Tell that to Koei. They made about a dozen of them.

[MottZilla]

Ok, little clarification. When I end a statement with :p that means I'm not dead serious.

It certainly would be nice if MMC5 was a viable option for whatever you want to make. But in all seriousness, It would be nice if someone could come with an affordable MMC3 level mapper for homebrew/reproductions with mapper conversions.

MMC1 certainly is nice to have, but it also would be nice to have eight 1K section CHR swapping, three 8K PRG banks swappable + 1 fixed, and a decent scanline counter. I was just saying it would be a dream if you could use MMC5. But having something on the MMC3 level would be nice. The features I mentioned could be used by about any game that exceeds what you can do with MMC1.

[tokumaru]

I'd find it great if someone in the "scene" (bunnyboy?) created this new mapper, with 1KB CHR switching, 8KB PRG switching and a reliable scanline (cycle?) counter. Oh, and nametable layout selection. I'd love this mapper, and would use it for all my projects.

The problem is that since no game exists for this mapper, there is no incentive to create it. At the same time, if a mapper doesn't exist, nobody is going to program games for it.

Maybe the best shot would be to implement this "standard homebrew mapper" into the current emulators (after all features have been discussed here), and hack commercial games to work with it. It's features should accommodate most existing games without problems. With these games converted, there would be an interest making repros of them, and then there is a demand for a hardware implementation.

This could mean the end of the dependency of homebrewers on commercial carts, that will only get more scarce with time. I'm using the MMC3 for my game, but I'm not using the scanline counter for water effects, because I'm breaking all the rules. Instead I have special palettes to use underwater, which is very restrictive. I'm sure the game would look awesome with raster effects, but I'm not doing any because of the crappy scanline counter.

[Bregalad]

I'd find it great if someone in the "scene" (bunnyboy?) created this new mapper, with 1KB CHR switching, 8KB PRG switching and a reliable scanline (cycle?) counter. Oh, and nametable layout selection. I'd love this mapper, and would use it for all my projects.

What you describe furiously reminds me the MMC5.

Also, remember that a game is something else than its mapper. People here seem to only talk about mappers and all, but you can do a decent amount of raster effect with mapper 0 without much problem, it just is a little harder. In fact a scanline IRQ counter only make things easier for the programmer, but it doesn't allow the impossible..

Can't say that without seeing the MMC5 game first. We have yet to see such a complex homebrew that requires the features of the MMC5, but if it does happen, it will probably be a good game. Nobody would be crazy enough to make a crappy game for the MMC5 just for the heck of it. The person who does it will probably know what they are doing.

I was going to make a MMC5 RPG back then but I moved to a smaller project to increase my chances of success. Once it's done I'll do a RPG for sure but I don't know if I will do it on MMC5 as planned or if I'll move to a simpler mapper. It depends if I want to sell the game or not, currently I don't know much about selling NES game so I don't care for this, but in the future this may change.