MMC7 (RxROM); Proposed MMC5 Modifications

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

MMC7 (RxROM); Proposed MMC5 Modifications
by Dr. Floppy on 2012-01-31 (#89432)

MMC5 --> MMC7
Register Modification Outline

General: Upgrade EXRAM to 2kB, mapped to $5800-5FFF.

APU Registers: unchanged

$5105: %10 = NTC ($5800-5BFF); %11 = NTD ($5C00-5FFF)

(MMC5 used %11 to identify the single-tile floodfill screen.)

$5106: same (floodfill tile ID)

$5107: [DCBA ..PP]

DCBA = Override NT with Floodfill Tile (0 = off; 1 = on)
PP = Attribute bits (same as MMC5)

Other Registers: unchanged

I take it FPGA is still the most logical route towards achieving this vision?

by 3gengames on 2012-01-31 (#89433)

TL;DR, but my thoughts:

Don't supersede a mapper not 100% understood yet. Make your own with MMC5-like features. The idea of making a new mapper with a base of another mapper defeats the purpose of variety.

And yes, a FPGA. A big one. A more expensive one then it's worth probably.

by tokumaru on 2012-01-31 (#89434)

Nobody has even recreated the MMC5 inhardware yet, so it's probably too soon for an MMC7. Also, no homebrewer has come close to making a game that would greatly benefit from the MMC5's features.

It seems that your proposed additions are so minor that they could be implemented as a variation of the MMC5 itself, instead of requiring a whole new mapper with it's own name.

by Dr. Floppy on 2012-01-31 (#89436)

3gengames wrote:
TL;DR, but my thoughts:

Don't supersede a mapper not 100% understood yet. Make your own with MMC5-like features. The idea of making a new mapper with a base of another mapper defeats the purpose of variety.

Granted, I intentionally restrained myself from making this my personal wish-list / dream mapper. I figure it's best to cut my teeth on something manageable and branch outward from there.

Quote:
And yes, a FPGA. A big one. A more expensive one then it's worth probably.

Bigger than the NES cart shell?

tokumaru wrote:
Nobody has even recreated the MMC5 inhardware yet, so it's probably too soon for an MMC7. Also, no homebrewer has come close to making a game that would greatly benefit from the MMC5's features.

In your opinion, is that due to a problem with supply or demand? (And, speaking as someone currently working on a MMC5 game, I'd be intrigued to learn what the Dev community expects of such a thing.)

Quote:
It seems that your proposed additions are so minor that they could be implemented as a variation of the MMC5 itself, instead of requiring a whole new mapper with it's own name.

Truly? Even after replacing the 1kB EXRAM? Oddly enough, I originally anticipated this to be a MMC5 variant, but somebody convinced me that it was closer to its own thing.

The changes are admittedly minor, but the results they would make possible are (I think) more significant than those between MMC2 & -4, or MMC3 & -6.[/quote]

by tokumaru on 2012-01-31 (#89445)

Dr. Floppy wrote:
Bigger than the NES cart shell?

Not dimensions big, capacity big. =)

tokumaru wrote:
In your opinion, is that due to a problem with supply or demand?

Not sure. People generally don't want to make games if they think it will be hard to make carts of them, and nobody wants to create mappers for which no games exist... I imagine that games have to come first, and then there will be people interested in making the hardware.

Quote:
(And, speaking as someone currently working on a MMC5 game, I'd be intrigued to learn what the Dev community expects of such a thing.)

I can't speak for the whole community, but my personal opinion is that your game must have an actual necessity for the mapper's features. You must use extended attributes and the advanced banking capabilities, otherwise there are simpler mappers that you could use. And you must use these features well... if we can hardly tell you are using them you're doing it wrong. Patterns must be varied and backgrounds must be very detailed.

Quote:
Truly? Even after replacing the 1kB EXRAM? Oddly enough, I originally anticipated this to be a MMC5 variant, but somebody convinced me that it was closer to its own thing.

I'm not much of a hardware guy, but from reading your ideas it does look like something backward compatible could be made... But that somebody could very well know more about hardware than I do, so I'm not gonna say anything for sure!

by infiniteneslives on 2012-01-31 (#89447)

1KB of SRAM is nothing by today's standards of hardware. Even on current programmable logic. Adding memory hardly justifies a new mapper IMO but it's your mapper so really you could call it MMC-747 if you wanted.

Now I'm not as up on the MMC5 as I'd like to be at the moment. You've got bankswitching, counter, multiplier, sound gen, and 1/2KB ram. I don't have a feel for how much the sound would require, but nothing screams HUGE to me. A modest FPGA should suffice I would think. Bunnyboy says there's enough logic on the powerpak with his Xilinx Spartan 2. Not sure what he's using specifically but I'm guessing less than 1000 logic blocks.

I really don't know, but I wouldn't be surprised if it actually fit on my 644Mcell Mach X02 CPLD in the NESDEV1 devcart project. If not I'd bet it would fit on one of the larger CPLDs in the family.

by MottZilla on 2012-02-01 (#89449)

The MMC5 has a split screen capability, 8K of Sprites plus 4K of CHR at the same time, and probably something else we haven't mentioned. The MMC5 has 100 pins, so your device needs alot. Plus if you have a FPGA you have to load it usually. It's not like a fixed circuit that works instantly when power is applied.

Really if it were that simple to slap a MMC5 on a FPGA, CPLD or whatever, it would have been done already. Maybe someday someone will clone the MMC5, but it really is the most complicated mapper that exists barring maybe that weird pirate mapper 90. Even still though MMC5 probably beats mapper 90 for its features and such.

by infiniteneslives on 2012-02-01 (#89451)

MottZilla wrote:
The MMC5 has 100 pins, so your device needs alot. Plus if you have a FPGA you have to load it usually. It's not like a fixed circuit that works instantly when power is applied.

Really if it were that simple to slap a MMC5 on a FPGA, CPLD or whatever, it would have been done already. Maybe someday someone will clone the MMC5, but it really is the most complicated mapper that exists barring maybe that weird pirate mapper 90. Even still though MMC5 probably beats mapper 90 for its features and such.

A 100 I/O logic is a non-issue, and while it's big it's still not huge. And configuring the FPGA isn't a show stopper either, especially if you used a CPLD.

Who's really tried to replicate the MMC5? I think it hasn't been done because there isn't much motivation to do it. Or at least not by people who have the tools and know how. That and most homebrewers who may get excited about it's abilities have a long way to go to utilize all the capabilities of the MMC3 let alone the MMC5.

If the NES has been put on modest programmable logic I'm pretty sure it's within reason to do the same for the MMC5. There's just no one so far that's cared enough to do it that can.

by Bregalad on 2012-02-01 (#89452)

What the hell ?!?

by Denine on 2012-02-01 (#89453)

Quote:
Not dimensions big, capacity big. =)

This means Big money, right?

Quote:
You must use extended attributes and the advanced banking capabilities, otherwise there are simpler mappers that you could use.

Excatly, There's no point in using MMC5 if you don't use at least one of it's features.

Quote:
(And, speaking as someone currently working on a MMC5 game, I'd be intrigued to learn what the Dev community expects of such a thing.)

Guess It's me? I remember mentioning it somewhere, but I didn't belive someone is going to remember about it.
And Question:Qas there ANY MMC5 game ever? I mean, GAME(Not demo\hack etc).

by tokumaru on 2012-02-01 (#89454)

infiniteneslives wrote:
You've got bankswitching, counter, multiplier, sound gen, and 1/2KB ram.

You forgot the most complex part (IMO): it keeps track of what the PPU is doing by watching the memory fetches, so that it can provide attribute data (attributes can be applied to individual tiles, rather than 16x16-pixel areas) and pattern data (512 tiles can be used for sprites and thousands can be used for the background instead of the usual 512 we have for everything) at the correct times.

by Shiru on 2012-02-01 (#89455)

Of course there were MMC5 games, otherwise the mapper would be unknown.

by Denine on 2012-02-01 (#89456)

@Shiru
Ahaha, I'm sorry.I wasn't precise.
I mean, was there any homebrew games for MMC5?

by tepples on 2012-02-01 (#89458)

tokumaru wrote:
People generally don't want to make games if they think it will be hard to make carts of them, and nobody wants to create mappers for which no games exist... I imagine that games have to come first

And these games might be PC prototypes written in C++ or C# or Python (pygame/pyglet) or something. Can Lua in FCEUX simulate missing mapper features?

Quote:
my personal opinion is that your game must have an actual necessity for the mapper's features. You must use extended attributes

And even I found a way around a requirement for extended attributes in an otherwise-NROM game. At first I thought I'd have to use extended attributes to make a grid of 8x8 pixel tiles with arbitrary colors, but Drag and I ended up figuring out how to use dithered 3-color tiles and keep it NROM.

by loopy on 2012-02-01 (#89459)

As others have said already, it's fun to think up new hardware, but who's going to use it? (or make it?) Personally, I'd rather work on a mapper that does something new and unique (for the NES), like inserting a background layer, or have a vertex buffer + rasterizer. Or HDMA-like effects.

I've been holding on to this since I don't really like releasing incomplete stuff, but since you're working on a MMC5 game and I haven't worked on it in quite a while, here's a link to my MMC5 powerpak implementation in its current state.

Oh, and FWIW.. your proposed changes are minor enough that the powerpak should be able to do it without much trouble (maybe no audio though).

by MottZilla on 2012-02-01 (#89463)

infiniteneslives wrote:
A 100 I/O logic is a non-issue, and while it's big it's still not huge. And configuring the FPGA isn't a show stopper either, especially if you used a CPLD.

Who's really tried to replicate the MMC5? I think it hasn't been done because there isn't much motivation to do it. Or at least not by people who have the tools and know how. That and most homebrewers who may get excited about it's abilities have a long way to go to utilize all the capabilities of the MMC3 let alone the MMC5.

If the NES has been put on modest programmable logic I'm pretty sure it's within reason to do the same for the MMC5. There's just no one so far that's cared enough to do it that can.

The pins was more about using a cheaper CPLD. No one has tried cloning the MMC5 cause it wouldn't be cheap to make and what is the point exactly? To make bootleg games? The only other reason would be to clone it for the PowerPAK to run those games.

As tokumaru said it does some important watching of the CHR bus for certain effects and capabilities. It's not just a MMC3 on steroids. It would be neat if it was cloned but I would say you are right no one has cared enough to try, but also those that could pull it off are probably not interested as the pay off is not much.

Also if you really need something better than MMC3 or FME7 I think you might as well make your own mapper with exactly the features you need.

by infiniteneslives on 2012-02-01 (#89469)

MottZilla wrote:
Also if you really need something better than MMC3 or FME7 I think you might as well make your own mapper with exactly the features you need.

Yeah I'd agree with that, not much point in figuring out how the MMC5 does what it does. You're better off spending that time creating your own to your needs. At that point you're also able to minimize the mapper and logic to lowest cost devices.

by MottZilla on 2012-02-01 (#89473)

loopy wrote:
As others have said already, it's fun to think up new hardware, but who's going to use it? (or make it?) Personally, I'd rather work on a mapper that does something new and unique (for the NES), like inserting a background layer, or have a vertex buffer + rasterizer. Or HDMA-like effects.

I've been holding on to this since I don't really like releasing incomplete stuff, but since you're working on a MMC5 game and I haven't worked on it in quite a while, here's a link to my MMC5 powerpak implementation in its current state.

Oh, and FWIW.. your proposed changes are minor enough that the powerpak should be able to do it without much trouble (maybe no audio though).

Any details on what is and isn't implemented? I don't think until now there has been any working MMC5 support. I tried Castlevania 3 and it started up ok and looked alright through the first level. But I forget if later on it uses features that might not be implemented or not.

by Karatorian on 2012-02-01 (#89490)

Personally, I doubt there's little use for all of MMC5's features (nevermind more) for anything other than the existing library of commercial MMC5 games. I agree that there seems to be more value (intellectually and financially) in making a mapper does only what one needs. Especially when the alternative is to clone a mapper that hasn't even been fully reverse engineered.

That said, the MMC5 does inspire one sometimes. Just the other day, I was thinking extended attributes would be cool. I had an idea that nobody actually uses the tiny native sprites of the NES, and then I realized attribute clash basically dictates 16x16 or larger "objects", which calls for larger sprites. I think the end results could look a lot different (but subtly) than most NES games.

But the game I had in mind for this, doesn't need all the rest of the MMC5's tricks. So, I might use it for dev, but for production, I don't think it'd be ideal.

by tepples on 2012-02-02 (#89491)

I thought of a relatively simple circuit that just provides the smaller attribute areas that people think of when they hear "MMC5":
Read $2000-$23BF, $2400-$27BF, $2800-$2BBF, $2C00-$2FBF: Enable CIRAM and load address bits 0, 1, 5, and 6 (corresponding to the tile row and column within a nametable byte) into an internal latch
Read $23C0-$23FF, $27C0-$27FF, $2BC0-$2BFF, $2FC0-$2FFF: Disable CIRAM, enable an attribute RAM on the cart, and combine the PPU address bus with this internal latch to make the attribute RAM address
$3000-$37FF: Linear access to attribute RAM

This would require about 10 inputs to watch PA0-PA9 (in addition to the PA10-PA13 you already get with most advanced mappers) and 12 outputs to control the attribute RAM's enable and address bus.

by tokumaru on 2012-02-02 (#89493)

That's a pretty cool idea, tepples. It's actually a lot simpler than I thought it had to be. If only adding more palettes was this easy...

by lidnariq on 2012-02-02 (#89511)

I'd actually designed something like this, uh... looks like a year ago but never had a reason to build it. The plan was actually for an all-RAM cart and 4-screen mirroring (because you can't buy <8kB RAMs anymore)

I didn't get as far as actually making the control signals, but here's the schematic I'd gotten most of the way through:
Wide digital schematic

Since I was building it in 74-series chips, using a latch or a multiplexer were equal in cost, so I went for the one that was easier.

IC2: Latches the lower 8 bits of the name table address for repetition on the attribute table fetch. Also passes the lower 8 bits of the address for pattern table fetches
IC4A: Passes the top 4 bits of the name table address. Also passes the middle 4 bits of the address of pattern table fetches.
IC4B: Passes the corresponding bits from the attribute fetch so that CHRRAMA contains the same 12 bit address for both the name table and attribute table fetches.
IC5A&B: On the attribute fetch, repeats the top two bits from the fetched byte so that we don't need to predict which bits the PPU is actually reading
IC6: Transparent buffer for everything except attribute table fetches.
IC3: Latches the lower 6 bits of the attribute tile fetch for use in pattern tables.
IC7: Selects what 4kB bank is mapped into $1000 in the PPU.
Not shown: Something to drive CHRRAMA12..A19 during nametable and attribute fetches. Could be 7 transistors and a buffer to map it into the top 8kB.

Because I don't know (is it known?) how to distinguish between dummy name+attribute table fetches for the sprites, this design works around that by just having $0000 use the extended attributes and $1000 doesn't. Or vice versa, I didn't actually place the specific logic.

by Dr. Floppy on 2012-02-03 (#89538)

MottZilla wrote:
Really if it were that simple to slap a MMC5 on a FPGA, CPLD or whatever, it would have been done already. Maybe someday someone will clone the MMC5, but it really is the most complicated mapper that exists...

infiniteneslives wrote:
Who's really tried to replicate the MMC5? I think it hasn't been done because there isn't much motivation to do it. Or at least not by people who have the tools and know how.

What's the first step towards cloning- complete documentation of the chip itself? Which I gather can only be attained via transistor tracing and/or decapsulation? I made a general inquiry into the latter several months ago; as fate would have it, I accepted a lucrative job offer a few days later, and my free time to pursue such interests took a major nosedive.

That said, I'm chomping at the bit to resume this cause. What sort of lab would be able to decapsulate/analyze/photograph the MMC5 to the extent necessary for total documentation?

loopy wrote:
I've been holding on to this since I don't really like releasing incomplete stuff, but since you're working on a MMC5 game and I haven't worked on it in quite a while, here's a link to my MMC5 powerpak implementation in its current state.

Oh, and FWIW.. your proposed changes are minor enough that the powerpak should be able to do it without much trouble (maybe no audio though).

Awesome! I just received a PowerPak for Xmas, and being able to test my game out on real hardware during development is going to be a huge help!

by tepples on 2012-02-03 (#89539)

Dr. Floppy wrote:
What sort of lab would be able to decapsulate/analyze/photograph the MMC5 to the extent necessary for total documentation?

These guys might be able to point you in the right direction.

by infiniteneslives on 2012-02-04 (#89552)

Dr. Floppy wrote:
What's the first step towards cloning- complete documentation of the chip itself? Which I gather can only be attained via transistor tracing and/or decapsulation? I made a general inquiry into the latter several months ago; as fate would have it, I accepted a lucrative job offer a few days later, and my free time to pursue such interests took a major nosedive.

I just received a PowerPak for Xmas, and being able to test my game out on real hardware during development is going to be a huge help!

The decasulation is an option but a painful for what would seem the low payout (usually the case with decapsulation IMO). Is there a reason you're looking for this much accuracy? It seems if you're developing a game your time would be severely better spent just redesigning the features of the MMC5 you'd like to use. Your game doesn't need to have 100% MMC5 accuracy, just features that work as you use them. You could even make something exceedingly better than the MMC5 with all the time it would take to decap it. That and build a ton of carts of your game with all the money you would have spent on decapsulation.

by Dr. Floppy on 2012-02-05 (#89633)

infiniteneslives wrote:
The decasulation is an option but a painful for what would seem the low payout (usually the case with decapsulation IMO). Is there a reason you're looking for this much accuracy?

It chagrins me that MMC5 still isn't fully understood by the community. I believe that serves as a disincentive for MMC5 coding and development (let alone cloning), which in turn suppresses overall interest in MMC5-related activity. In short, it's a depressing feedback loop that I wish to see broken. If I have to spend a couple hundred bucks (or more) to get things moving in the right direction, it's something I'm more than happy to do.

by 3gengames on 2012-02-05 (#89634)

But even though it has lots of good features, the sound can't be used normally on an NES, no CHR-RAM, too expensive to replicate by any means, etc. It doesn't make sense other than knowing how it works to know how it works. I don't think it's totally not understood, I think it's very well understood but just not use able for anything else.

by Dr. Floppy on 2012-02-05 (#89637)

3gengames wrote:
But even though it has lots of good features, the sound can't be used normally on an NES, no CHR-RAM, too expensive to replicate by any means, etc. It doesn't make sense other than knowing how it works to know how it works. I don't think it's totally not understood, I think it's very well understood but just not use able for anything else.

So it's mostly the extra bells & whistles that prevent RetroUSB (or whomever) from cloning MMC5, as opposed to the incomplete documentation?

by bunnyboy on 2012-02-06 (#89642)

What parts are incomplete or not understood? The wiki seems to have full register descriptions, and multiple open source emulators support all the MMC5 games. Other than verifying how it syncs with the PPU I don't see what decapping would gain.

by tepples on 2012-02-06 (#89647)

bunnyboy wrote:
Other than verifying how it syncs with the PPU I don't see what decapping would gain.

Yes, verifying how it syncs with the PPU, so that we can 1. make a clone that syncs the same way, and 2. predict what effect VRAM writes during vblank would have.

by Dr. Floppy on 2012-02-06 (#89672)

tepples wrote:
bunnyboy wrote:
Other than verifying how it syncs with the PPU I don't see what decapping would gain.

Yes, verifying how it syncs with the PPU, so that we can 1. make a clone that syncs the same way, and 2. predict what effect VRAM writes during vblank would have.

Would that information be discernible from the decapsulation process described here: http://soltecelectronics.com/products_quality_electronic_parts.html? (about one screen down)

by infiniteneslives on 2012-02-06 (#89673)

tepples wrote:
bunnyboy wrote:
Other than verifying how it syncs with the PPU I don't see what decapping would gain.

Yes, verifying how it syncs with the PPU, so that we can 1. make a clone that syncs the same way, and 2. predict what effect VRAM writes during vblank would have.

Why is it seen as so impossible to redesign this logic ourselves???

by loopy on 2012-02-07 (#89683)

MottZilla wrote:
Any details on what is and isn't implemented? I don't think until now there has been any working MMC5 support. I tried Castlevania 3 and it started up ok and looked alright through the first level. But I forget if later on it uses features that might not be implemented or not.

Vertical-split scrolling and sound are disabled in this one. Everything else SHOULD work, but there are bugs here and there that I haven't tracked down yet. Occasional gfx corruption on some Koei games, for example (EXRAM gets trashed somehow). The special MMC5 stuff (extended nametable, extended attribute, fill mode, split BG/sprite CHR banking) and IRQs work fine as far as I know.

by MottZilla on 2012-02-07 (#89689)

Excellent. Thanks Loopy. Even if it is incomplete it's better than the absolutely nothing that we had before. Thanks again for all the other mappers you've contributed too.

by naI on 2012-02-07 (#89696)

Yes, thanks Loopy! This is not bad for a beta mapper!

by bunnyboy on 2012-02-07 (#89697)

infiniteneslives wrote:
Why is it seen as so impossible to redesign this logic ourselves???

It isn't seen as impossible, just hard/expensive with no big benefit. And redesigning it doesn't need an exact copy so the knowledge already contained in emulators is almost certainly enough. Decap would just get the precise logic, which could probably be figured out with other tools like logic analyzer instead.

Kevtris' console shows its not impossible, but he did cheat with hooks into the NES PPU

by marvelus10 on 2012-02-07 (#89698)

loopy wrote:
MottZilla wrote:
Any details on what is and isn't implemented? I don't think until now there has been any working MMC5 support. I tried Castlevania 3 and it started up ok and looked alright through the first level. But I forget if later on it uses features that might not be implemented or not.

Vertical-split scrolling and sound are disabled in this one. Everything else SHOULD work, but there are bugs here and there that I haven't tracked down yet. Occasional gfx corruption on some Koei games, for example (EXRAM gets trashed somehow). The special MMC5 stuff (extended nametable, extended attribute, fill mode, split BG/sprite CHR banking) and IRQs work fine as far as I know.

Thank you, keep up the great work.

by infiniteneslives on 2012-02-08 (#89705)

bunnyboy wrote:
infiniteneslives wrote:
Why is it seen as so impossible to redesign this logic ourselves???

It isn't seen as impossible, just hard/expensive with no big benefit. And redesigning it doesn't need an exact copy so the knowledge already contained in emulators is almost certainly enough. Decap would just get the precise logic, which could probably be figured out with other tools like logic analyzer instead.

Yeah that was kinda what I was thinking. I guess the point I was trying to make was cracking the secrets of the MMC5 isn't the only option for us to gain these features. That's what most people seem to believe. It's simpler, cheaper, and less uncertainty for us to just re-design logic to provide similar features to what the MMC5 has. There's no point to crack it open, just design something for ourselves... Especially if you're looking to create a game that you'd like to produce.