It sounds like you're saying that they're similar boards but designed for different ROM/RAM sizes and end up having enable/write registers in different/mutually-incompatible places, that don't actually matter for extant game compatibility?

Mostly I was drawing an analogy between MMC6 and SOROM. Here's how MMC1 (iNES mapper 1) behaves:

These are completely identifiable from ROM size and PRG RAM size. PRG RAM size is stored in one place for late iNES and another for NES 2.0, in part because very few emulators ended up supporting late iNES's PRG RAM size field. Emulators that don't support PRG RAM size bytes are using PRG ROM size to identify SUROM and CRCs to identify SOROM and SXROM.

Quote:

We should be able to just look up a mapper from a table, using only the mapper and submapper numbers. There should not have to be extra code to check this-or-that other field. Yes it's true that MMC6's only practical use is if you want 1k PRG RAM. It should always be accompanied by a 1k PRG RAM specification, but that's not how a mapper should be selected.

My suggestion was "any with two SRAMs acts like MMC6", but after looking at it for a while, I guess it'd be better to explicitly indicate that a program uses independent enabling of halves of PRG RAM.

The more I look at this, the more annoying the current state of things seems to be. When I look at kevtris' original submappers draft (submapper.txt), it is very clear that the goal is disambiguating extant games that currently do CRC or other heuristic checks to select a mapper implementation. This is a usability improvement to the iNES mapper set, not an attempt to specify every hardware quirk that ever was.

When I look at the wiki page (NES 2.0 submappers) I see no goal or criteria as to how submappers are selected. Here's a short list of problems I can see at a glance, there's probably more:

MMC1 half of kevtris' suggestions were confusingly "deprecated" because someone thinks the size fields should be used to select the mapper instead. (Why the hell are we already "deprecating" things? This is a new spec!) I've said before that I don't think size fields are an appropriate place to select a mapper, because it muddies the specification significantly.

002/003/007/UxROM/CNROM/AxROM proposes submappers for emulation of bus conflicts. Why? Does failing to emulate them cause a problem for any game?

MMC3 - confusingly different than kevtris' original set. What happened to "hardware mirroring" and is this necessary for any games? I actually thought that MMC6 was the "poster child" for why we needed submappers and I thought it was bizarre to find it not on here. (It was assigned to submapper 1 in kevtris' original doc, and Nestopia UE actually implemented this already.) Why did we throw away both of kevtris' suggestions before reassigning the slots to new ones?

MMC5 - what does "wishlist" mean? Does this have anything at all to do with compatibility with existing software?

VRC4 - why would we want to create submappers for board permutations that don't exist?

34 - why did we discard the "union bond" mapper variation? Was it not used for anything?

Kevtris' document seems quite practical to me, and straightforward to implement. The version on the Wiki is currently unusable, and not even close to compatible with Kevtris' list. How do we expect to create a standard like this?

What I want to suggest again is that we treat this just like iNES mapper allocation. Find the problem case first, then create the submapper to resolve it. Don't create solutions to problems that don't exist. Submapper (and mapper) allocation must follow the needs of published software. This is not a wish-list. This is not a catalog of endless hardware variations. The wiki covers that kinda stuff in detail, and if anyone ever wants to make use of yet-unused board/mapper incompatibilities, publish the software that needs it first, then you can allocate the submapper.

As for whether PRG-RAM or other fields should be used to select a mapper implementation, I vote against this, but if it really is consensus I would accept it. I think the more additional steps of logic one has to compute when selecting a mapper implementation, the more difficult and confusing the specification becomes. I think Kevtris may have had the same reasoning.

(Similarly, I also think it's really dumb to call this "NES 2.0" instead of "iNES 2" but I'm not going to fight for a meaningless name change if this is really what we want to call this thing.)

My suggestion was "any with two SRAMs acts like MMC6", but after looking at it for a while, I guess it'd be better to explicitly indicate that a program uses independent enabling of halves of PRG RAM.

Yes, the independent enabling is exactly what makes it MMC6.

Though, the problem I'm facing is not whether someone could theoretically build an MMC3 with 1k of PRG-RAM. The problem is that the wiki's "standard" is patently unusable, and conflicts with kevtris' other "standard", and there's no consensus between emulators that have tried to adopt NES 2.0. Because of this I can't possibly hack Startropics and have that hack run in existing emulators.

It's an arbitrary decision whether to use PRG-RAM size for disambiguation where possible, or whether to use submapper number, but you must realize that kevtris already made this decision, and changing it later and re-assigning those submappers works against the effort to establish a standard! Startropics was the poster child for why we needed NES 2.0 and it's been totally bunged up by this needless effort to avoid spending a submapper on it (??). I think it's an extremely bad idea to start putting special case logic in every time we could save a submapper allocation. The real world implementations of NES 2 mapper 1 and 4 are already in a bad way because of it.

The submappers aren't scarce, and the problem cases are very small! Of all the problem cases there seem to be fewer problem games than there are submapper slots, and even if we ran out (which we won't) we could just create a new NES 2.0 mapper to hold extra sub-mappers (presumably with the same low-8 value as the original).

Honestly I think we should scratch what's on the wiki, and start over from kevtris' document, adding only what is needed to solve existing problems that kevtris missed (or possibly correcting errors he made, if any).

You want to know why the wiki's submappers definition differ from kevtris's?

Because I read his reference and decided it was patently unusable. They were underdescribed (Mindseeker + mapper 80), overfine (VRC4?), apply to non-existant things (see next ¶), and their release coincided with a time when he was taking a break from the forum.

It was necessary to throw the whole thing out and start with just a list of where things were needed. It contains more mistakes than useful starting points.

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.

So, let's talk specifically about StarTropics. 1- There is no definition of MMC6 that makes sense with a PRG-RAM quantity other than 1 KiB.1b- There is no definition of SUROM vs SNROM that makes sense without the latter having 512 KiB PRG-ROM; there is no definition of SNROM, SOROM, and SXROM that makes sense without those three having 8, 16, and 32 KiB of PRG-RAM.2- The decision was made to allocate a field to specify the amount of PRG-RAM AS WELL AS a generic submapper field3- Why specify the same exact information twice in the header ("This is StarTropics ... oh, and just in case you weren't paying attention, this is StarTropics")3b- Why specify the same exact information twice in the header ("This is Titanic 1912 ... oh, and just in case you weren't paying attention, this is Titanic 1912")3c- I'd repeat myself for all the S?ROM games, but ugh.

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.

MMC1 half of kevtris' suggestions were confusingly "deprecated" because someone thinks the size fields should be used to select the mapper instead. (Why the hell are we already "deprecating" things? This is a new spec!) I've said before that I don't think size fields are an appropriate place to select a mapper, because it muddies the specification significantly.

I originally made these changes in the interest of denormalization, or removing redundant data to reduce possibility for inconsistency. The only truly distinguishable behavior is whether CHR A16 disables PRG RAM.

CHR A16 always goes to PRG ROM A18 if it exists.

CHR A15-A14 always go to PRG RAM A14-A13 if they exist.

CHR A15 selects from two PRG RAMs if both exist.

CHR A16 goes to PRG RAM /CE only on SNROM. Not making this a submapper is arguably my mistake.

rainwarrior wrote:

002/003/007/UxROM/CNROM/AxROM proposes submappers for emulation of bus conflicts. Why? Does failing to emulate them cause a problem for any game?

It causes a problem for new homebrew games in development. It also is known to cause defects for mapper 144, which relies on ROM always winning the bus conflict on the D0 line.

rainwarrior wrote:

MMC3 - confusingly different than kevtris' original set.

I have removed the revised set for this mapper in favor of coming restoration of at least part of the original set.

rainwarrior wrote:

What happened to "hardware mirroring" and is this necessary for any games?

Hardwired mirroring was available only on the TEROM and TFROM boards, and it was never actually used in any game on those boards. The games most likely to have used it use mapper 206 (Namco 108): Karnov, RBI Baseball (licensed version), and Ring King. But all were released on DEROM or DE1ROM instead.

rainwarrior wrote:

MMC5 - what does "wishlist" mean? Does this have anything at all to do with compatibility with existing software?

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.

We should limit the list to games that are incompatible with submapper 0, i.e. the games that would have required a CRC or other kludge to run.

For example, 001:5 suggests SEROM / SHROM / SH1ROM, which is a large list of games. Do all of these really fail on submapper 0? (I strongly suspect not, but requires more research.)

What I'm trying to do by listing the games is provide both the rationale for a submapper's existence, and also give the implementer a test case they can use to verify it. If a ROM technically uses that board variant but is compatible with submapper 0 it's counterproductive to list it.

My complaint was that I found a different implementation for this in Nestopia UE, Nintendulator, and puNES when I started looking into it. I'll take a look at MESS.

Nestopia only grew submapper support in the past month.Nintendulator doesn't implement submappers at all.MESS does according to the version of that page on the wiki as of 2014-01-xx.I can't speak to puNES, since it's not open source.

Quote:

Let's not consider these things.

Seriously? Your response to my entire argument is "I don't care" ?

Having the same information in the header twice is actually a serious complaint. So, fine, answer me this:* An emulator author writes an emulator using kevtris's original standard.* A ROM is marked as being MMC1 submapper 2, SOROM, but is marked as having 8+0 KiB of RAMWhat is the correct behavior?- Crash?- Refuse to load the ROM because it's talking nonsense- Assume the submapper is correct, and ignore the PRG-RAM size. If so, why on earth did kevtris add the PRG-RAM size field?- Assume the PRG-RAM size is correct, and ignore the submapper #. If so, why on earth do we care what the submapper # is?

Analogy first: if I have a database table with configuration records, I'd much rather looking up a single record by primary key then by matching all the properties. PK is guaranteed unique, combination of field values are not necessarily so.

for iNES 1.0 roms, mapper is determined by major mapper # and deriving the particular variant by properties of the game. the is accepted as necessary but terrible right? The whole point of submappers for 2.0 was to avoid that business. Why ignore that in favor of a more complex method? If a major mapper # isn't sufficient to determine configuration, I'd rather have an explicit value telling me what it should be rather than trying to scope it out from one or more other properties.

And secondly, if there are some cases where we deem submapper necessary, the submapper should be the go-to for all cases where the major mapper isn't enough. Consistency is important. Submappers can define every variation ram+other properties that could ever be needed. Is the reverse guaranteed? I think you'd have a hard time proving that true.

Really if we settle on submappers as the authority, ram units will likely be redundant in many cases. I'm ok with that- it's easy enough to disregard in case a submapper is given. There may still be cases where it's useful, e.g. no submapper specified but the rom expects some amount of ram.

So in summary: explicitness and consistency are priority, and flexibility should also be maintained.

Thank you, I will review this and try to add the relevant information to the wiki.

lidnariq wrote:

Quote:

Let's not consider these things.

Seriously? Your response to my entire argument is "I don't care" ?

That was a direct response to tepples proposing an MMC6 with oversize PRG-RAM, and not to anything else. I'm sorry for the confusion.

lidnariq wrote:

Having the same information in the header twice is actually a serious complaint. So, fine, answer me this:* An emulator author writes an emulator using kevtris's original standard.* A ROM is marked as being MMC1 submapper 2, SOROM, but is marked as having 8+0 KiB of RAMWhat is the correct behavior?- Crash?- Refuse to load the ROM because it's talking nonsense- Assume the submapper is correct, and ignore the PRG-RAM size. If so, why on earth did kevtris add the PRG-RAM size field?- Assume the PRG-RAM size is correct, and ignore the submapper #. If so, why on earth do we care what the submapper # is?

If the header is inconsistent, behaviour is unspecified. The implementer can choose how to handle this, it's not important for us to specify what happens in response to every possible header, only what happens in response to well-formed headers.

My primary objection to the change is that I think the mapper functions like what registers do should always be specified in the same place. My secondary objection is that it contradicted the precedent kevtris' original implementation set.

I presumed the PRG-RAM size field is to differentiate mappers that have the same register set but different PRG-RAM sizes, just like there are plenty of mappers with the same or compatible registers sets but different PRG-ROM sizes (e.g. MMC3 with no PRG-RAM vs MMC with PRG-RAM). That's what its purpose looks like to me, at first glance, but you are asking for it to also be part of the selection of register function (as well as other size fields).

What I actually propose is that we should have both in the spec. Put a submapper for each of the MMC1 size variants, and for MMC6, and advise that both should be specified together. An implementer can choose to override the submapper choice with size fields if they choose, or vice versa. The redundancy supports both approaches if the headers are well formed, and honestly I would not expect malformed headers to be a problem anyway (we actually have a central hub to disseminate information here, it's not like the iNES 1 days anymore).

Do programs incompatible with the existing submappers have to be games, or can they also be test ROMs?

If a submapper's only reason for being is to run a test ROM, I don't really understand why anyone would want to implement it...

Mostly I'm trying to understand your view on resolving the chicken-and-egg issue inherent in creating a new mapper. At one point during the creation of a new mapper for the Action 53 project, I was at that point: "I have a game in progress. Here are screenshots of the game running on an existing mapper with reduced features, as well as a spec and test ROM for a new mapper or submapper. Implementing the new mapper would allow all features to be implemented." Should someone in this situation obtain a compiler, learn C, and modify an existing emulator?

1. Moved any implementation that is unimplementable or speculative to a proposal page. This included stuff that was "wishlist", merely trying to open discussion, or otherwise didn't have any submapper assignments or

2. Added game examples for everything that I could find information on so far.

3. Attempted to format everything in a consistent way.

I believe these changes have made no actual change to the specification as-is, I'm merely trying to reorganize the information. Tepples did change the MMC3 assignment, which was a response to my request, but otherwise everything is the same. My intent is that the wiki page should always be ready for implementation and that proposals and future changes should be done elsewhere.

Who is online

Users browsing this forum: No registered users and 4 guests

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