MMC7 (RxROM); Proposed MMC5 Modifications
Moderator: Moderators
-
- Posts: 47
- Joined: Mon May 09, 2011 7:02 pm
MMC7 (RxROM); Proposed MMC5 Modifications
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?
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?
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.
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.
-
- Posts: 47
- Joined: Mon May 09, 2011 7:02 pm
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.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.
And yes, a FPGA. A big one. A more expensive one then it's worth probably.
Bigger than the NES cart shell?
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.)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.
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.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.
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]
Not dimensions big, capacity big. =)Dr. Floppy wrote:Bigger than the NES cart shell?
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.tokumaru wrote:In your opinion, is that due to a problem with supply or demand?
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.(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'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!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.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
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.
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.
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.
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.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
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.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.
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.
This means Big money, right?Not dimensions big, capacity big. =)
Excatly, There's no point in using MMC5 if you don't use at least one of it's features.You must use extended attributes and the advanced banking capabilities, otherwise there are simpler mappers that you could use.
Guess It's me? I remember mentioning it somewhere, but I didn't belive someone is going to remember about it.(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.)
And Question:Qas there ANY MMC5 game ever? I mean, GAME(Not demo\hack etc).
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.infiniteneslives wrote:You've got bankswitching, counter, multiplier, sound gen, and 1/2KB ram.
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?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 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.my personal opinion is that your game must have an actual necessity for the mapper's features. You must use extended attributes
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).
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).