The bank number would have to straddle the nametable select. The 512K limit of the canonical oversize extension avoids this straddling.

Meh, I don't see why you think this "straddling" is a problem.

As it is, the wording on the wiki is confusing IMO (on the basis of "why are only 5 of the bits of the octal latch used?", basically what tokumaru has been saying all along). At the very least it should mention the possibility of getting 4 MB with an octal latch, and the fact that the 512 KB "limitation" only exists if the programmer (for some reason) would want to avoid the straddling (and doesn't have the option to move the nametable selection bit, for yet another strange reason).

You could also use the upper three bits for CHR bank switching if you'd like. Or the four lower bits can be for CHR, and the three upper bits can be for PRG. Or you could also interleave the two banks so that every bit of the byte alternates between being a bit of the PRG bank and a bit of the CHR bank, with the nametable select right in the middle. You could also swap out some of the bits for copy protection diodes, too, so that every bit is randomly a PRG bank bit, a CHR bank bit, or an input to a diode that replaces either bus with open bus.

You could also use the upper three bits for CHR bank switching if you'd like. Or the four lower bits can be for CHR, and the three upper bits can be for PRG. Or you could also interleave the two banks so that every bit of the byte alternates between being a bit of the PRG bank and a bit of the CHR bank, with the nametable select right in the middle. You could also swap out some of the bits for copy protection diodes, too, so that every bit is randomly a PRG bank bit, a CHR bank bit, or an input to a diode that replaces either bus with open bus.

Awesome ideas, Drag. There's just so much you can do with an octal latch... How about you write all of that to the AOROM page in the wiki?

(and doesn't have the option to move the nametable selection bit, for yet another strange reason).

There are two strange reasons. First, the popular CF or SD to NES adapters can't handle more than 512 KiB of PRG ROM. This is considered an acceptable loss, as the only things using more are Action 52 and the pirate multis that inspired it. Second, it'd be a new mapper, and someone making an original game for a new mapper needs three different skills: assembly language programming to write the game, C++ on a PC OS to write the mapper support for an emulator with which to step through it instruction by instruction, and soldering to make the cart with which to test on hardware.

The 512 KiB limit that I wrote on the wiki is what I know the existing emulators agree on. Which emulator is known to implement the "straddling" behavior?

(and doesn't have the option to move the nametable selection bit, for yet another strange reason).

There are two strange reasons. First, the popular CF or SD to NES adapters can't handle more than 512 KiB of PRG ROM. This is considered an acceptable loss, as the only things using more are Action 52 and the pirate multis that inspired it. Second, it'd be a new mapper, and someone making an original game for a new mapper needs three different skills: assembly language programming to write the game, C++ on a PC OS to write the mapper support for an emulator with which to step through it instruction by instruction, and soldering to make the cart with which to test on hardware.

The wiki page is talking about a theoretical variant from a hardware point of view. It shouldn't have anything to do with whether Flash carts or emulators are capable of supporting it, or whether it presents too much work for a developer.

I think if an extension of the mapper is commonly implemented by emulators this is worth mentioning.

The statement as-is, however, is confusing. It goes right into a potential hardware implementation, but if you're implementing in hardware, the octal D latch allows up to 4MB, the 512k statement is simply wrong. If you're talking about a common emulator extension, the 512k statement is OK I think.

Some emulators allow bit 3 to be used to select up to 512 KB of PRG ROM for an oversized AxROM. In hardware this could be implemented by using an octal latch in place of the quad latch (74HC377), though an octal latch has 3 more bits that could be used to switch up to 4 MB of PRG ROM.

Ideally we should probably move most of Disch's documents over to the corresponding non-iNES description page and leave only a redirect or short description behind. Large portions of the wiki are in a pitiful state of Don't Repeat Yourself.

Technically, yes but the mapper 7 page is an insignificant stub, and should really be a redirect. Actually, I'll do that now.

I agree, also, thank you very much for your recent modifications, they are very relevant.

I think most iNES mapper #xxxx pages should redirect to their corresponding mapper pages, unless for some exceptions, like mapper #37 or mapper #118.

Also who had that great idea of pasting Dish notes in the 1st place ? I mean, all mappers were already explained, and then some great genius had the great idea of simply pasting Dish notes on the bottom of that without asking whether this is relevant or sensible. So of course it's no wonder why every info is here twice... Dish's note should be left as it and not be on the wiki. OR all the mapper pages on the wiki should be removed and only Dish' notes should remain but I wouldn't advocate this.

EDIT : Seems that Zeromus is the culpirt... so if anyone is bothered because of the repeated info, complain to him...

Now, in my humble opinion, I think everyone is confused because names like AOROM, UNROM, etc... are used as if they were mappers. They are not. Sorry guys but just no. They are merely boards made by Nintendo that implements some mappers.

Once again :

Nintendo-made boards can implement multiple mappers, as seen on Crazy Climber (UNROM, not mapper #2) or Bird Week (CNROM, not mapper #3)

A mapper can be implemented with multiple (i.e. infinite) hardware : The american version of Wizard & Warriors III is not implemented with an AxROM family board despite being mapper #7, I can also made my own mapper #7 board using a dozen of transistors mounted as latches instead of a 74HC161 as a lach, etc, etc...

I also think that discrete mappers needs to be explained on a single page (as I mentionned above before my edit), but in my humble opinion, this page should be the iNES mapper page, NOT the board (i.e. AxROM) page. AxROM, UxROM, etc... should just be considered as the Nintendo implementation of one or multiple discrete logic mappers, and should be mentioned as such (along with how they were implemented, and whether solder pad config and bus conflicts should be present). In other words, I see no reason why the AxROM page doesn't looks like the SxROM page.

So here is my vision :

All boards or family of boards have a page, explaining ONLY the boards, which hardware they have, which solder pad configs they do, and which mapper(s) they implement. (by the was there is no concept of "oversize" here, since we only discuss existing hardware on those page)

Another page (MMC1, mapper #2, MMC3, mapper #7, etc, etc...) is explaining the behaviour of every mapper, and how they are programmed in a user's viewpoint. They do not mention any hardware nor non-ASIC chips nor boards, just links to known board pages implementing those hardware. The concept of oversize of course belong to here.

Mapper #1 should redirect to MMC1, and mapper #4 should redirect to MMC3 and so on, there is no room for duplication here. HOWEVER, mapper #7 should not redirect anywhere because there is no ASIC, so instead the board is "free to be implemented in the way the user wants it to", including AxROM, an Acclaim made board, a repro pack from RetroZone or anything else. The implementation can have SRAM or not have it, can be "oversize" or not be, etc, etc....

I think it's a judgement call on a case by case basis whether to have separate pages for boards and mappers. In the case of AxROM and Mapper 7, I think these two things are related coherently enough that they belong on the same page. There's not enough to say about mapper 7 alone or AxROM alone to make it worth having two pages, much better to keep them in the same place.

Unfortunately the title of the page can only be one thing, so it's either going to be named mapper 7 or AxROM, but that's just a limitation of wikis that we must live with. As long as they both redirect, and we make it clear in the lead (e.g. acknowledge and bold all the terms that redirect), I think this is okay. I don't think it really matters which title the page gets. Actually "AxROM" is really a name we made up for the mapper, isn't it? Kind of a funny case. AOROM, AMROM, ANROM all redirect to AxROM, etc. If there are other boards that fit this mapper, redirect them to this page if appropriate and acknowledge them there.

If a board fits several mappers, it's worth giving it its own page. Probably a small disambiguation-style stub to the various mappers it can be used for.

If a single mapper fits several boards (which is a common case), unless there's a significant amount of unique text needed for them, gather them to the same page and acknowledge them properly (like with AxROM). If there's too many distinct variations or the page looks like a mess with all of the information, split the article. Just don't split it up until there's enough information on the page to warrant it.

If multiple mappers fit the same related class, this is another case where they should be gathered together. For example, mapper 24 and 26 should both redirect to VRC6.

Yes, Disch's notes should all be incorporated into the articles and then removed. I did this for them on the expansion audio pages as I went over them. I'm glad zeromus added them to the wiki, because it's good to gather all the information there. It's only the start of what needed to be done, though. We need to go through and clean it up.

Anyhow, in summary, yes, I think every mapper should have a page in the namespace, and so should every important named board. If what they represent is sufficiently the same, redirect one to the other to avoid duplication of information. Whether to do this is often subjective, but we can talk out the weird cases.

In the case of AxROM and Mapper 7, I think these two things are related coherently enough that they belong on the same page. There's not enough to say about mapper 7 alone or AxROM alone to make it worth having two pages, much better to keep them in the same place.

Honnestly I don't know.AxROM would be about the chips, pinout, and bus conflicts (including the bus-conflict-killing circuit in ANROM and additional enable pin on AOROM).Mapper #7 would be about the register at $8000-$ffff that is written to in order to select mirroring and a 32kb PRG bank.

I can perfectly see those 2 being separate, just like SxROM is separate to MMC1. However, if they are separate, the info definitely shouldn't be duplicated, of course.If they are one single and unique page, then it should probably be called mapper #7, so that it also includes any future mapper #7 homebrew on a custom PCB and the American version of Wizard and Warriors III. There is definitely no point in having a dedicated article for this rare/unique board, of course.

The problem is that this is a whole mess, as there is not only multiple boards implementing the same mapper, and multiple mappers on the same board, there is also multiple boards for multiple mappers (e.g. the Namco 106 implements "MMC3", just like the MMC3 does implement itself, but there is also MMC3 boards which aren't mapper #4, etc...)

This is why the "software" and "hardware" of a mapper should be, in my opinion, as separated as possible. While it's true that 99% of UxROM boards implements mapper #2, it's not always true, etc, etc...

This is why the "software" and "hardware" of a mapper should be, in my opinion, as separated as possible. While it's true that 99% of UxROM boards implements mapper #2, it's not always true, etc, etc...

I think a 1% usage doesn't usually justify a new article, only a note in most cases. It's a subjective decision, of course, though.

Anyhow, either way we organize the articles, I definitely agree it is very important to not confuse the hardware and software wherever they do not coincide transparently. If a note applies only to hardware it should be written so that it's clearly not about the iNES mapper, and vice versa.

Also who had that great idea of pasting Dish notes in the 1st place ? I mean, all mappers were already explained

"All"? A lot of especially more obscure mappers didn't have any docs on-wiki until Disch's notes were imported.

Quote:

Nintendo-made boards can implement multiple mappers, as seen on Crazy Climber (UNROM, not mapper #2) or Bird Week (CNROM, not mapper #3)

True, and I've tried to use the mapper number when referring to mappers other than the most common associated with a particular board, such as "UNROM #180" or "CNROM #185".

Quote:

The american version of Wizard & Warriors III is not implemented with an AxROM family board despite being mapper #7

The NesCartDB entry for that game says "PCB Class: ACCLAIM-AOROM", or in other words, "This is Acclaim's board that implements the behavior first established by the AxROM series."

Quote:

Mapper #1 should redirect to MMC1, and mapper #4 should redirect to MMC3 and so on, there is no room for duplication here. HOWEVER, mapper #7 should not redirect anywhere because there is no ASIC

Should there be separate pages for each Chinese, retroUSB, or infiniteneslives clone of MMC1, MMC3, and other mappers first implemented using an ASIC? Should there be pages for "INL-ROM v1", "INL-ROM v2", and "INL-ROM v3"?

Who is online

Users browsing this forum: No registered users and 0 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