Why don't we still have an aftermarket MMC5 board?
Is the repro market primarily targeted by suppliers (leaving homebrew second)?
NOOPr wrote:
Why don't we still have an aftermarket MMC5 board?
Primarily because of it's complexity. It requires a large amount of expensive hardware, and it's functionality is still not 100% known.
Quote:
Is the repro market primarily targeted by suppliers (leaving homebrew second)?
Homebrew primarily targets simpler mappers. There's only a couple homebrews to date that have utilized MMC3. I've never had a homebrewer express they're willing to spend 50% or more on boards for their homebrew game. Like it or not, but it's the repro market that has helped create the options that homebrewers now have available to them.
All that said if you have a homebrew game that utilizes MMC5 features and can communicate the specifics it makes creation of a potentially simplified board specific for your needs. It's much easier to recreate MMC5 only for your specific needs that are well known, than a 100% accurate MMC5 replica for that's not known as well.
My current boards used for MMC3/FME7 only use about half the available logic resources. They can fully decode the CPU bus, but only enough of the PPU bus to implement MMC2/4. If you can come up with a subset of MMC5 that fits in the current board design you can effectively get it for roughly the same cost as MMC3.
1- They'd be drastically more expensive for no significant market.
2- A bunch of people feel that the MMC5 stretches the capabilities too far.
2b- even with 8x8 attributes or the left-and-right split screen, you still have the limited master palette and colors-per-tile-or-sprite and sprites still can only cover 25% of the width.
3- It'd be also more expensive than just adding lots of bankswitched CHR-RAM, and that gets you most of the nice things anyway.
Once you shave away the really exceptional things the MMC5 does, it's not all that different from an MMC3/FME7/VRC4.
One thing I like about the MMC5 is that you have IRQs yet still can switch the entire CHR-ROM range with a single write. Very useful for clean screen splits and elaborate status bars with sprites in them. On the MMC3 with its stupid index register, changing the entire 8 KiB takes an eternity.
infiniteneslives wrote:
Homebrew primarily targets simpler mappers. There's only a couple homebrews to date that have utilized MMC3.
Most MegaCat titles use MMC3, it's convenient to target both for programming and for inventory.
As I see it, this is a chicken vs. egg situation... The hardware people don't want to make a complex, expensive board since there's nothing interesting to put on it (licenced or homebrew), and programmers don't want to code MMC5 software because there's no hardware where to put it.
tokumaru wrote:
As I see it, this is a chicken vs. egg thing... The hardware people don't want to make a complex, expensive board since there's nothing interesting to put on it (licenced or homebrew), and programmers don't want to code MMC5 software because there's no hardware where to put it.
While this is probably true for some, and it was for me previously, it's no longer the case IMO. I get requests for MMC5 rather frequently. Previously I didn't think I could make one for a reasonable price. I don't think that's the case anymore, partially due to lower prices of high density CPLD/FPGAs as year pass on. Other part of that cost reduction is a project I'm working on to dual port single port memory via time multiplexing which greatly reduces the cost (smaller CPLD/FPGA and/or removal of dedicated dual port RAM). Homebrew probably doesn't see it as a reasonable price, but I think MMC5 can be done fully assembled with memory and all for a sale price around $30 or better. So at this point for me the biggest road block is finding the development time to actually make it a reality.
I'm guessing there are a number of other people that would like to make and offer MMC5 replica boards, they're probably getting the same constant requests I do. But designing a MMC5 capable board is no easy feat, let alone on a budget. I would guess that development time/effort/skills is what's standing in most people's way that might be motivated to replicate and sell the MMC5 on a budget.
Unless I'm mistaken, one final problem is that the MMC5 is still not 100% characterized, and hardware clones could accidentally enshrine behavior other than what the original ASIC does.
We're probably close enough, since the known weird edges (8 banks for 8x16 sprites mode and IRQ clock source) are now characterized, but ...
infiniteneslives wrote:
I get requests for MMC5 rather frequently.
From serious developers? Where are all the cool MMC5 homebrews then? Most of the demand for MMC5 I see here in the forum comes from beginners whining about the 16x16-pixel attribute zones, which 99.9% of existing NES games adhere to.
lidnariq wrote:
Unless I'm mistaken, one final problem is that the MMC5 is still not 100% characterized, and hardware clones could accidentally enshrine behavior other than what the original ASIC does.
I agree, but one could argue this case still exists for nearly all ASIC mappers. Part of the reason this is not fully characterized is lack of motivation and/or proper tools to do so. For example, I believe I can test the original enough to fully characterize it. But I'm not motivated nor knowledgeable enough about MMC5 behavior to determine this right now. Once I have gross functionality and better understanding of what to test exactly I'll perform necessary tests to fully characterize the original as needed. It's certainly a hurdle that needs to be overcome, but I don't see it as the primary reason it's not currently available. Either way I think we can get there without a decap, just need right combo of skills, motivation, & tools.
tokumaru wrote:
infiniteneslives wrote:
I get requests for MMC5 rather frequently.
From serious developers? Where are all the cool MMC5 homebrews then? Most of the demand for MMC5 I see here in the forum comes from beginners whining about the 16x16-pixel attribute zones, which 99.9% of existing NES games adhere to.
No, as mentioned earlier the demand doesn't start with homebrew development:
infiniteneslives wrote:
Like it or not, but it's the repro market that has helped create the options that homebrewers now have available to them.
When I very first started offering MMC3 & FME7 replicas years ago, it was the repro market that made the endeavor profitable long enough until homebrews were able take advantage of what I had to offer. Right now, I believe the biggest demand for MMC5 is that zelda hack but I'm sure there are others I don't pay that close of attention.
I think the main alluring thing with MMC5 would be it's increased PRG and CHR size for homebrew, but INL is right in that there really is only demand for it on the repro side of things. Pretty much any homebrew can get by on MMC3.
Perhaps making a mapper based on MMC3 that offered a 8Mbit PRG and CHR would be a good thing to design, because it would satisfy the hacks that need more rom space (given that they be converted to MMC3), and could give homebrewers more room to play with as well.
getafixx wrote:
Perhaps making a mapper based on MMC3 that offered a 8Mbit PRG and CHR would be a good thing to design
The design is rather trivial and already done supported by some emulators I believe? Just use bits 6 & 7 of the PRG bank registers and you've got support for 2MByte of PRG-ROM. I think there's some megaman hack with MMC3 that's 1MByte someone was asking me to support years ago but I've kinda forgotten about it since. In general the non-standard options I offer to homebrew developers in private discussions is turned down due to lack of emulator support despite the fact it wouldn't increase board cost.
EDIT: I neglected expanding CHR beyond 256KByte. I agree it would be nice to have a standard definition of how to do this, but it's a bit difficult esp without software. Perhaps some unused $A000/A001 bits could be used, but probably best to define 8 more registers in bank select register $8000 with unused bit 3.
infiniteneslives wrote:
In general the non-standard options I offer to homebrew developers in private discussions is turned down due to lack of emulator support despite the fact it wouldn't increase board cost.
Why is that a bad thing? If the game wasn't supported by Flashcarts or most emulators, wouldn't that help sales in the long run as the game wouldn't be dumped and emulated within a day of selling?
Adding support back to emulators is utterly trivial, if someone actually does release a oversize MMC3-clone image. It won't meaningfully prevent copying, but will deter development.
And I think we might accidentally have earmarked one of the random high mapper numbers to mark "MMC3 but with more PRG bank bits" to signal to ROM hackers that oversize MMC3 actually requires different hardware. Maybe?
infiniteneslives wrote:
EDIT: I neglected expanding CHR beyond 256KByte. I agree it would be nice to have a standard definition of how to do this, but it's a bit difficult esp without software. Perhaps some unused $A000/A001 bits could be used, but probably best to define 8 more registers in bank select register $8000 with unused bit 3.
IMO, I'd vote in favor of a VRC4-like or mapper 90-like CHR banking scheme.
Quote:
Why is that a bad thing?
You still need to develop and test it with the help of emulators.
getafixx wrote:
infiniteneslives wrote:
In general the non-standard options I offer to homebrew developers in private discussions is turned down due to lack of emulator support despite the fact it wouldn't increase board cost.
Why is that a bad thing? If the game wasn't supported by Flashcarts or most emulators, wouldn't that help sales in the long run as the game wouldn't be dumped and emulated within a day of selling?
It's not that it's a 'bad thing' it's that the effort required to adding emulator support to aid in their development is outside the scope of their project generally. While not strictly required, most developers see emulator support as a requirement which I understand.
lidnariq wrote:
IMO, I'd vote in favor of a VRC4-like or mapper 90-like CHR banking scheme.
Yeah there are probably better ways. But ultimately whatever we 'decide' doesn't hold much water when it comes time for someone to make use of it for software development of a game unless we go through the trouble to create test roms and add support to whatever their emulator of choice is (which may be any/all of them making it an impossible task).
Just getting support into FCEUX and Mesen should satisfy most developers.
Should I just make test ROMs for 1 MB PRG+32K CHR oversize MMC3?
Hence suggesting VRC4 or mapper 90 for development; support for both is fairly widespread, and already supports 512K (or more) CHR.
Admittedly, VRC4 only supports 256K PRG, and thus larger images have the same problem as oversize MMC3.
tepples wrote:
Just getting support into FCEUX and Mesen should satisfy most developers.
Sure FCEUX support goes a long way. But it's not much help for developers that want to support digital release of their rom though. Try all we want, there's very little we can do to standardize new mappers and their variants at this point. New mappers? Sure, we do it all the time. Create a standard that everyone agrees is adequate? Good luck...
I just tested FCEUX SVN and Mesen with a Holy Mapperel ROM built with MMC3 + 1024K PRG ROM + 32K CHR RAM. Both worked.
tepples wrote:
Should I just make test ROMs for 1 MB PRG+32K CHR oversize MMC3?
May as well go for broke and use all 8 bits of PRG banks for 2MByte if you're going through the trouble since the definition is trivial. I don't mind testing on hardware if it helps, I currently support up to 8MByte parallel flash if defined by the mapper.
I'd still be happier if we earmarked a different mapper ... or at least submapper ... for oversize MMC3.
Nestopia and Nintendulator were the ones that enforced the actual limits of the hardware... and I really don't see FCEUX could possibly be supporting more than 512K of PRG, either, given:
void Mapper4_Init(CartInfo *info) {
[...]
GenMMC3_Init(info, 512, 256, ws, info->battery);
info->Power = M4Power;
hackm4 = info->mirror;
}
NOOPr wrote:
Why don't we still have an aftermarket MMC5 board?
Is the repro market primarily targeted by suppliers (leaving homebrew second)?
A pretty simple answer is just that it took
many years to get to what we have now. MMC5 is a harder problem still, and will take longer.
The idea of an MMC5 mapper is easy to have. It's obvious, and it's just as obvious that it
could be done. ...but actually doing it requires one or several people dedicating a portion of their life, and taking some amount of financial risk in it. That part ain't trivial.
Then I guess I'll have to track down the bug in Holy Mapperel that causes a false success indication.
The other possibility is that FCEUX is trying to enforce that limit and somehow failing.
lidnariq wrote:
And I think we might accidentally have earmarked one of the random high mapper numbers to mark "MMC3 but with more PRG bank bits" to signal to ROM hackers that oversize MMC3 actually requires different hardware. Maybe?
I had misunderstood CaH4e3's remarks and had written in the wiki that Mapper 224 was oversize TNROM. I have since corrected that mistake --- oversize TNROM is mapper 4, and Mapper 224 is Jncota KT-008 with the outer bank register at $5000.
lidnariq wrote:
I'd still be happier if we earmarked a different mapper ... or at least submapper ... for oversize MMC3.
I disagree. The fact that a ROM image has more than 512 KiB of PRG-ROM already unambiguously indicates that the MMC3 chip/clone must support it, so adding a new mapper or a submapper to convey that information is redundant. If we insisted that Mapper 4 be strictly limited to a maximum of 512 KiB of PRG-ROM because the original MMC3 had that limitation, then we would also have to insist that Mapper 3 be strictly limited to a maximum of 32 KiB of CHR-ROM because the original CNROM board had that limitation.
Aren't there boards that already can fulfill most of the desired features of the MMC5?
Large ROM support (1MB combined)
Flexible and small ROM paging sizes (8KB PRG, 1KB CHR)
Clean IRQs for screen splitting playfields from horizontal status bars (vertical is a bit out there)
Four unique nametables (not technically an MMC5 feature)
Unique palette entries for all background tiles, eliminating the 16x16 palette assignment restriction
PRG-RAM paging (support for more than 8KB of battery backed RAM)
The demand for MMC5 clones seems merely to promote piracy. Homebrew games generally lack the ambition to use MMC5 features. MMC5 clones real value are for reproductions of rare games and cartridge releases of popular hacks like Zelda Legend of Link, Rockman 4 Minus Infinity and Super Mario All-Stars NES.
I'll evaluate MMC3 and FME-7 against your requirements:
- Large ROM: Authentic MMC3 and FME-7 ICs are limited to 512 KiB PRG and 256 KiB CHR. But clones could expand the $8000, $A000, and $C000 windows to an 8-bit bank number, allowing use with 1 MB PRG ROM and 32K CHR RAM.
- Small CHR window sizes: MMC3 has it but slightly uneven as two of the CHR windows are 2K and either $8000 or $C000 is fixed to the penultimate PRG ROM bank. FME-7 has uniform 8K PRG and 1K CHR including banked WRAM or ROM at $6000.
- Clean interval timer for line scrolling and other raster effects: MMC3 is fairly clean so long as you don't try to use more than 4K of sprites in a scene. Background and sprite tile sharing can be done, but it's through setting one of the sprite windows to the same bank number as one of the background windows, not through bit 0 of the tile number of 8x16 pixel sprites. FME-7 is sort of messy if you want multiple splits. In order for IRQ acknowledgment jitter not to accumulate from one split to the next, you have to let the low byte of the timer value free-run, giving multiples of 256 cycles (about 2.25 scanlines on NTSC) as usable periods after the first split. It's not quite as clunky as using DMC as a timer, as at least the first split is fairly precise, but it's pretty close.
- Four unique nametables: Attested with MMC3 (TVROM); combining that with the TLSROM/TKSROM setup could provide dual 4-screen.
- Finer attribute grid: Nope. That's something only the MMC5 can currently do among well-known mappers.
- WRAM paging: FME-7 has it; MMC3 doesn't. I've in the past proposed adding "Bank at $6000" to bits 0-3 of MMC3 $A001.
I imagine a lot of ROM hacks that change the underlying game's mapper from something else to MMC5 could be ported to an oversize MMC3.
NewRisingSun wrote:
The fact that a ROM image has more than 512 KiB of PRG-ROM already unambiguously indicates that the MMC3 chip/clone must support it, so adding a new mapper or a submapper to convey that information is redundant.
The entire point of wanting a separate mapper is to denote that the MMC3 ASIC (and its contemporary clones) can't handle more than 512K of PRG. My objective is specifically signaling to people making ROM hacks that "no, you can't just casually get that". Historically we've had serious problems with people testing against emulators, not against hardware, and making things that couldn't be put on, let alone run on, hardware.
Even worse are the people who denied this reasoning, and patched the emulator to remove the size limitation to support their ROM hack.
Quote:
If we insisted that Mapper 4 be strictly limited to a maximum of 512 KiB of PRG-ROM because the original MMC3 had that limitation, then we would also have to insist that Mapper 3 be strictly limited to a maximum of 32 KiB of CHR-ROM because the original CNROM board had that limitation.
The difference is that oversize CNROM has a trivially-implementable definition; for up to 128K CHR, it's literally just "connect more wires".
Historically, MMC3 is not as trivial.
Now, of course, INL is offering to make that hardware, and the objection largely is bypassed. I'm having a hard time weighing the historical reasons for why emulators had to enforce these constraints with this offer.
This has, of course, come up before a bunch.
viewtopic.php?t=10474 viewtopic.php?t=12866 viewtopic.php?p=180204#p180204
Once I build a new test ROM specific to MMC3 clones with oversize PRG ROM, I'll take it to a new topic.
infiniteneslives wrote:
Primarily because of it's complexity. It requires a large amount of expensive hardware, and it's functionality is still not 100% known.
infiniteneslives wrote:
Like it or not, but it's the repro market that has helped create the options that homebrewers now have available to them.
It's clear now. Thanks!
infiniteneslives wrote:
All that said if you have a homebrew game that utilizes MMC5 features and can communicate the specifics it makes creation of a potentially simplified board specific for your needs. It's much easier to recreate MMC5 only for your specific needs that are well known, than a 100% accurate MMC5 replica for that's not known as well.
My current boards used for MMC3/FME7 only use about half the available logic resources. They can fully decode the CPU bus, but only enough of the PPU bus to implement MMC2/4. If you can come up with a subset of MMC5 that fits in the current board design you can effectively get it for roughly the same cost as MMC3.
Good to know that the possibility to build such board exists
Of course I did a few MMC5 boards that support subset of MMC5 features, used by some remakes (Super Mario All Stars, Zelda Legend of Link). By just implementing the needed features, I was able to fit even in EPM240 CPLD:
* Different PRG/CHR bankins schemes,
* Scanline couter (the way MMC5 it does by waiting for three consecutive PPU read fetches - but I just limited it to observing A13),
* different bank for sprites & background (SM All Stars used it),
* EXRAM used as additional CPU-RAM (used by utilizing external 64 kB RAM).
The board that I used has wired to CPLD: !ROMSEL, CPU-R/!W, M2, CPU A0-A14, D0-D7, PPU !WE, PPU-A10-A13.
I just had to add PPU !RD signal.
Things that are harded to implement is EXRAM used by both CPU & PPU. It requires CPLD that has resources for implementing internal 1024 bits of dual port RAM, most larger FPGA (Spartan XC3S100E) can do it but they need external configuration meomry and so the initialization takes tens of ms and the CPU need to be haltet for that time. But maybe using external memory + 74245 would be the choice (like pirated MMC5 bootlegs do)