lidnariq wrote:... list of thoughts on kevtris' submappers ...
Okay, good, so you had some reasons to make the changes (except the "spelling mistakes" complaint, that's completely tangential and not really related to validity of a submapper). The problem I think we need to address is there is no documentation or accountability for this. i.e. a new user can't come in and find out why anything is in the state it's in, I'll get to my proposal to address this in a moment.
lidnariq wrote:There are myriad documented games that rely on the presence/absence of bus conflicts on discrete logic mappers. You can search the wiki for them.
These games should actually be listed in the submappers article, which is part of what I'm about to propose below...
lidnariq wrote:So, let's talk specifically about StarTropics. ...
... MMC6 is 1:1 with 1k RAM, the MMC1 variants are 1:1 with various ROM/RAM sizes ...
... Why specify the same exact information twice in the header? ...
I think we already covered all of this in this thread already. This information was acknowledged. My opinion is that the implementation of a mapper should be selected exclusively by the mapper+submapper number, rather than adding a weirdo "look elsewhere in the file" rule wherever we could possibly save a submapper. It's a bad precedent that complicates the specification. I think it's more important to have a consistent use of fields in the specification than it is to eliminate every possible redundancy from them. I also think that making this arbitrary decision to change the method of mapper selection specifically breaks continuity with kevtris' earlier attempt to establish this specification, which I think is a bad thing. The spec can be functional either way, I suppose, but it was already started in the
other way. We've also applied this change inconsistently ("deprecation" for mapper 1, complete reassignment for mapper 4), which makes it even worse.
lidnariq wrote:Finally, despite your complaint: The reason the NES 2.0 submappers haven't been deployed is EXCLUSIVELY because there isn't a ROM set that uses them. That's it. Nothing less, nothing more.
Anyway, Nintendulator already uses PRG RAM size to determine MMC1 behavior and the presence of RAM presence to handle Low G Man. And MESS implements everything as on the wiki ... except for MMC3, because I didn't decide on anything (other than that kevtris's recommendations were inadeuate) until after etabeta implemented things.
My complaint was that I found a different implementation for this in Nestopia UE, Nintndulator, and puNES when I started looking into it. I'll take a look at MESS. "There isn't a ROM set that uses them" is a very good point, actually, but it isn't really the truth; it looks like many in-development emulators are trying to adopt iNES 2.0 already. The lack of standardization would be worked out by having some ROMs to test the implementation against, though, which would actually be great.
tepples wrote:"iNES 2" is the name of a version of an emulator. This emulator does not support NES 2.0 format.
An emulator that nobody uses or ever refers to except in oblique "did you know" reference to the file format.
tepples wrote:lidnariq wrote:There is no definition of MMC6 that makes sense with a PRG-RAM quantity other than 1 KiB.
I can think of one definition (which I'm not proposing to fully implement): ...
Let's not consider these things.
Okay, so with that response out of the way, I want to make my proposal. The problem as I'm looking at it is that it's not practical for anyone looking at the wiki page to understand 1.
what is this submapper for? and 2.
do I want to implement it?. These are important questions for an implementer, and it's not reasonable to make someone read hundreds of forum posts and wiki pages to learn these things. I made a proposal on the wiki about
how to allocate new submappers in the future, but here are two immediate changes I would very strongly suggest:
1. Move anything that is speculative (e.g. wishlist, incomplete draft, etc.) off the article. The article should be
a list of things that can be implemented now, not a nebulous warning of the future.
2. For every submapper,
list the games that require it. This answers both questions I posed above.
If we did this, a new user (like me) looking at the article would be able to understand exactly why each submapper exists, what games to look at to test and understand the problem, and can evaluate whether it's even important for them to support those particular games. It would solve the chain of authority problem we're having by making the rationale for the submappers completely opaque.
The
proposal for how to add new submappers was basically to maintain this standard of disclosure going forward, and to establish a process for evaluating it and maintaining continuity.