It is currently Fri Jun 22, 2018 8:38 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Apr 25, 2018 5:40 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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).

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 5:42 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 5:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 5:53 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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...

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 5:56 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
I just tested FCEUX SVN and Mesen with a Holy Mapperel ROM built with MMC3 + 1024K PRG ROM + 32K CHR RAM. Both worked.


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 6:00 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 6:21 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
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;
}


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 6:33 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6347
Location: Canada
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.


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 6:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
Then I guess I'll have to track down the bug in Holy Mapperel that causes a false success indication.


Top
 Profile  
 
PostPosted: Wed Apr 25, 2018 7:26 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
The other possibility is that FCEUX is trying to enforce that limit and somehow failing.


Top
 Profile  
 
PostPosted: Thu Apr 26, 2018 5:08 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 527
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.


Top
 Profile  
 
PostPosted: Thu Apr 26, 2018 7:04 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 647
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.

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


Top
 Profile  
 
PostPosted: Thu Apr 26, 2018 7:27 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Thu Apr 26, 2018 10:02 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7223
Location: Seattle
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


Top
 Profile  
 
PostPosted: Thu Apr 26, 2018 11:06 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20165
Location: NE Indiana, USA (NTSC)
Once I build a new test ROM specific to MMC3 clones with oversize PRG ROM, I'll take it to a new topic.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group