I was checking the
AOROM page and found this part very strange:
Quote:
In theory, it would be possible to implement the bank select register with a 74HC377 octal D latch, allowing up to 512 kilobytes of PRG ROM, but no Rare game used this much memory.
With 7 bits for indexing banks you could go as high as 4MBytes, so where did the 512KBytes figure came from? Is that because of the position of the mirroring bit (there's only 1 unused bit between the bank index and the mirroring bit)? That wouldn't stop you from using all 7 bits, you'd just get a strange layout for them (or you could even bump the mirroring bit to the highest bit).
Also, the mention of Rare is pretty random, and even looks like something tepples would do here in the forums, but in the Wiki it's just plain confusing. Why would Rare be the only developers that would make large games?
Most AxROM games were developed by Rare.
Quote:
Most AxROM games were developed by Rare.
There is plenty of mapper #7 games not made by Rare at all. Solstice comes to mind.
It's not like the VRC mappers for example who are exclusive to Konami.
Quote:
With 7 bits for indexing banks you could go as high as 4MBytes, so where did the 512KBytes figure came from?
It comes from the iNES mapper #7 extension that implements the 4 lower bits only for bank switching. Sure you could use the 3 upper bits as well, but it wouldn't be iNES mapper #7 any more. Check the good old (and innacurate) Firebug doccument for details.
However, mapper 2 (UNROM extention) and 3 (CNROM extention) are extended to 8-bits of bank select, as there is no mirroring select bit. This may be weird, strange and make few sense, but that's just the way it is.
It makes plenty of sense to me. Oversize extensions are defined so as not to have to extend one field past another field. With UNROM, BNROM, and CNROM, there's only one field in the written value, so the extension doesn't need to cross another field. (This excludes CNROM with protection diodes, which has been assigned to a different mapper.) With AOROM, on the other hand, the mirroring page bit is in the way.
This discussion would be better placed on the wiki itself:
http://wiki.nesdev.com/w/index.php?title=Talk:AxROMAlso, just click history to find out who wrote something.
As for the statement at hand, I would agree this seems strange and out of place. BNROM is a good mention as a variant of AxROM. A theoretical octal latch variant isn't a useful digression. It doesn't exist. The size described is wrong. The mention of Rare is pointless (the point that Rare used AxROM a lot is valid, but that's already part of the lead paragraph). To top it off, I can think of 3 different sensible places to put the nametable bit, so it's not even something emulators should extend like we have with oversized BNROM. Without resolving this ambiguity this statement can't even be considered a proposal for an extended AxROM.
In contrast, a similar statement is given on the BNROM page and seems totally fine to me there for all the opposing reasons. (Oversized BNROM homebrew does exist and has emulator support, the size described is correct, Rare is not mentioned, and the extension to the existing mapper is unambiguous.)
I don't think there is any ambiguity in extending mapper #7, not is the size wrong.
Since the mirroring bit is bit 4, it allows to use unambiguously bits 0-3 for bankswitching, which allows for 2^4 = 16 banks of 32kb = 512kb.
An octal latch is only one of the ways such a mapper could be realized, there is no 5-bit latches chips, so you either have to buy 8-bit or use 2 chips of 4-bit (or do whatever you want, that isn't the point of this thread).
What is wrong, however, is the mention of Rare.
The 74377 suggestion is actually a
standardized notice, which takes a reason as a parameter. It defaults to "mask ROM would have been too expensive back then", which is fine for mappers whose oversize extension would exceed 1 MB, such as BNROM, CNROM, and UNROM. But for oversize extensions producing sizes that were plausible in the later NES era, I had to come up with a better excuse for why Nintendo didn't implement the suggestion. For example, later
Dragon Warrior games use 512 KiB of PRG ROM on the SUROM board, and
Mega Man 4 and
Mega Man 6 use 512 KiB of PRG ROM on the TGROM board.
Rare AOROM games:
21Non-Rare AOROM games:
13, including
5 developed by someone else but ported to NES by Rare.
So that makes 26 games developed or ported by Rare and 8 other.
Seriously what is that
http://wiki.nesdev.com/w/index.php/INES_Mapper_007 ?!
WTF ?
Such pages should be deleted, mapper 7 should redirect to AxROM page instead (and etc... for other mappers as well)
tepples wrote:
So that makes 26 games developed or ported by Rare and 8 other.
No doubt about that, but the fact that they were the ones to release the largest number of AOROM games doesn't automatically make them the only ones able to release a 512KB game on that board. Nowadays, any user in this board has higher chances of releasing such a game than Rare.
So what should I put down as the most likely reason why the oversize extension wasn't used during the NES's commercial era (which I take to mean pre-1997)?
Uhhh... The games they had to make fit nicely in 256KB? The developers were told they only had 256KB to work with because the purchased boards had 4-bit latches?
I honestly don't see why speculating on this is relevant in a page should be stating facts. Also, considering that "Rare" is an english word commonly used by game collectors, people not familiar with the company might get unnecessarily confused.
Here's a few guesses:
- ROMs cost enough (at the time) that the incremental cost for a 512KiB ROM meant one may as well use an ASIC.
- By the time games had enough assets to warrant a 512 KiB ROM, everyone was using ASIC mappers anyway.
- 512 KiB of data is awkward to manage with only 32KiB at-a-time banking and only 2 KiB of internal RAM.
- There were only 25ish games released by Nintendo with 512 KiB ROMs, out of approximately 1400. In a purely statistical sense, the odds of any given mapper instantiated with 512KiB ROM is fairly low.
lidnariq wrote:
- By the time games had enough assets to warrant a 512 KiB ROM, everyone was using ASIC mappers anyway.
There were some pretty late AOROM games though, like
The Lion King and
Aladdin, both released in 1995 (both are also pretty bad, specially when compared to their pirate counterparts).
tepples wrote:
So what should I put down as the most likely reason why the oversize extension wasn't used during the NES's commercial era (which I take to mean pre-1997)?
I don't think it's very useful to speculate about the past in this way on the wiki. It's fun to offer guesses here on the board, but the wiki is reference material. Irrelevant material impedes understanding, after a point.
At most it's worth mentioning the theoretical oversize variant using an octal latch. You could even link this forum discussion about it, if you want to give someone a handle to the speculation stuff, but I don't think it belongs on the article page. (It's not much more relevant than any of the infinity of other possible other ideas that could have been implemented in a similar board.)
I agree with rainwarrior, the speculation has no place in the wiki.
As if I were to tell why 512k mapper 7 was never made, I'd rather ask : which game HAD to use 512k mapper 7 ? None of course. So that's why it has never been done. Nobody outside of this forum would ever develop an entire game JUST for using a particular hardware configuration (yes, StarFox was made on the sole purpose to test the Super FX, but here we're not talking about a super new chip or technology, just an additional latch bit). End of story.
Quote:
- 512 KiB of data is awkward to manage with only 32KiB at-a-time banking and only 2 KiB of internal RAM.
I don't think it's awkward to manage, once you made up the tranpoline zone that is repeated in each bank. 32k banks also means less banks, so easier to manage.
Also the size of PRG banks has no relationship ever with RAM size.
Bregalad wrote:
Quote:
- 512 KiB of data is awkward to manage with only 32KiB at-a-time banking and only 2 KiB of internal RAM.
I don't think it's awkward to manage
I agree. 32KB out of 512KB isn't any harder to manage than 32KB out of 256KB.
Quote:
32k banks also means less banks, so easier to manage.
Interesting point, but I don't know if I agree with this. Even though there are less banks, you have to think more carefully about how you'll organize the code/data within them, always considering how the game engine will work, in order to minimize the amount of bankswitching operations per frame and the amount of data you have to copy to RAM.
Quote:
Also the size of PRG banks has no relationship ever with RAM size.
I think lidnariq's reasoning was that since you can only have one bank mapped at any given time, you can't access data from multiple banks at the same time, and with more RAM you could copy the data from one bank, swap another bank in and you'll effectively be accessing data from 2 different banks. Again, the total ROM size is mostly irrelevant anyway, so 512KB isn't any harder to manage than 256KB. If anything, 512KB would make things easier because you'd be able to duplicate some of the data to combine it with other things in different banks.
With 256K or more you could almost organize the game as a multicart. Perhaps that's why Battletoads includes such diverse play styles.
I'm quite fond of 32k banking. I like to divide the banks by function, e.g. one for music, a few for level maps, one for CHR tiles, one for gameplay code, etc.
The only thing I find it really unsuitable for is DPCM, unless you want to duplicate your samples across all banks that may be used during playback, but I am happy to live without.
How big is your game's NMI handler? If you hit a lag frame, the CPU could be in any bank while it executes.
tepples wrote:
How big is your game's NMI handler? If you hit a lag frame, the CPU could be in any bank while it executes.
The NMI code present in all banks could very well be a stub, like the Reset handler, that selects the bank with the actual code and jumps to it. The only difference is that you have to remember the index of the previous bank, in order to restore it before returning from the NMI.
The good thing is that you don't even have to sacrifice any time detecting whether the NMI interrupted the frame calculations, since the 32KB banking scheme allows you to change the CPU vectors. When there is no lag, you can safely select the NMI bank (which has the NMI vector point directly to the NMI handler) before waiting for VBlank. On the other banks, the NMI vector points to the stub NMI.
tepples wrote:
How big is your game's NMI handler? If you hit a lag frame, the CPU could be in any bank while it executes.
Who cares? Just duplicate a tiny NMI handler that saves the bank, switches in the correct bank, and jumps to the real NMI handler. Doesn't take many cycles.
Every bank has an NMI, RESET and IRQ vector, and corresponding code, obviously (though I'm not actually using IRQ for anything, it's just an RTI).
The bank switching routine is organized like a function call, it pushes the current bank number, changes banks, executes the routine from that bank, returns to finish by popping the original bank number and switching back to it before RTS to the place the banked routine was called from.
For an NMI, you can either have one true NMI routine and have all the other NMIs bankswitch to it, or simply duplicate it in each bank. For the time being, I'm duplicating it in each bank, since it's the simpler solution. The NMI itself is currently about 480 bytes of code (some is unrolled loops that could be taken in if needed). I don't really anticipate needing to save those bytes, but if I need them back, there's enough time left in vblank to include a bank switch (the NMI just does OAM DMA + 32 byte palette + 32 byte nametable, not too heavy a load).
As an aside, I really enjoy that the cc65 toolchain's separation of assembling and linking lets me assemble common code only once before linking it in all the banks that need it. (Assembling doesn't really take a significant amount of time, I just enjoy the conceptual efficiency.)
Also, the music runs in the NMI handler, but all of its code is in its own bank. This is obviously not part of the 480 bytes I just mentioned. The music routine would never run a whole frame, but I have a flag anyway to prevent a re-entrant NMI.
I actually turn the NMI once at startup, and then my game never turns it off. This lets the music continue while screen transitions are being uploaded with rendering off, etc. and as I was getting at above, there's no need to worry what bank was active when the NMI hit (lag frames or otherwise). When a bank call is made it remembers via the stack to return to the calling bank; that's all you need to do to keep it robust.
Back when I learned what mappers were, I thought working with 32KB banks would be very limiting, but now I realize that's not necessarily the case.
I think it's no more limiting than most other arrangements.
With 16k or 8k banks you have more fragmentation, wasted space that you can't fill at the edges of each smaller bank. On the other hand, you don't have to duplicate code, as you can have one bank of code read data from many banks. 8k banking is especially useful for Sunsoft style DPCM banking, if that's the kind of soundtrack you want.
With 32k banks you have the least amount of fragmentation, almost no ROM layout tetris to do, but some amount of code duplication is unavoidable. For example, in my case, the level unpacking code appears in each level data bank. DPCM duplication is another potential source of waste space, and multiple DPCM banks is probably out of the question.
So, the space tradeoff is probably a wash. DPCM is the biggest issue, in my opinion, but it depends on your soundtrack goal.
rainwarrior wrote:
As an aside, I really enjoy that the cc65 toolchain's separation of assembling and linking lets me assemble common code only once before linking it in all the banks that need it. (Assembling doesn't really take a significant amount of time, I just enjoy the conceptual efficiency.)
How did you do it? I thought code duplication in cc65 was only realistically possible with macros.
Well, if you assemble each bank separately, include the shared code in each bank but don't export its symbols, and carefully craft a linker script, it is certainly possible.
These are examples from blargg.
It's simpler than that. I just link each bank separately and combine the resulting binaries into the NES ROM. This way there's no potential conflict between symbols.
You don't need to link them together because 32k banks don't need to know about each other's symbols. The only interaction between banks is through the banked calls, which go through switching routine I described which has to be at a fixed location anyway. Similarly, all of my RAM reservations are gathered into a single object that gets linked with all of them.
You could link them all together, sure, but then you have to resolve the symbol conflicts. I did this in the past by using .scope around an .include of a shared code file, but once I realized the different banks didn't need to be linked together I abandoned this approach.
Ok, so each used 32K bank is a memory region in your linker script, and you use the
file attribute to link banks individually to output files and then, in the next pass, you make a NES file out of the generated binary files, with a script or another asm file that
incbins each bank? Or you forget the file attribute altogether and just generate several differently named bin files? (could easily be done that way with a makefile, and indeed be even easier)
No, I'm not using multiple output files in a single link. Each bank is its own separate link operation. They all use the same linker CFG, which looks like this, currently:
Code:
MEMORY {
ZP: start = $00, size = $100, type = rw, file = "";
STACK: start = $100, size = $100, type = rw, file = "";
BSS: start = $200, size = $600, type = rw, file = "";
PRG: start = $8000, size = $8000, type = ro, file = %O, fill = yes, fillval = $EA;
}
SEGMENTS {
ZEROPAGE: load = ZP, type = zp;
STACK: load = STACK, type = bss;
OAM: load = BSS, type = bss, start = $200;
RAM: load = BSS, type = bss;
ALIGNED: load = PRG, type = ro, start = $8000, optional = yes;
CODE: load = PRG, type = ro;
DATA: load = PRG, type = ro;
FIXED: load = PRG, type = ro, start = $FE00;
VECTORS: load = PRG, type = ro, start = $FFFA;
}
I just concatenate the header and binaries after linking.
ALIGNED is a place for a couple of timing critical routines, so I can be sure they don't cross a page.
FIXED is the place for the bankswitch routine, though I have also put my common NMI routine here.
Couldn't you hypothetically extend AxROM to a size as big as 4 MB with an octal latch? You wouldn't even need to move the nametable select bit if you didn't want to break compatibility with smaller AxROM games.
The bank number would have to straddle the nametable select. The 512K limit of the canonical oversize extension avoids this straddling.
tepples wrote:
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.
There's just so many possibilities.
Drag wrote:
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?
thefox wrote:
(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?
tepples wrote:
thefox wrote:
(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.
Edit: Here, how does
this sound?
Quote:
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.
Sounds okay, expect this is an oversize mapper #7, not an oversize AxROM, since it wouldn't belong to AxROM (= boards made by Nintendo) any longer. I know I'm being a bit picky ^^
Technically, yes but the mapper 7 page is an insignificant stub, and should really be a redirect. Actually, I'll do that now.
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.
Quote:
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.
One that's been nagging at me is
PPU scrolling vs
The skinny on NES scrolling. These definitely need a merge, but I haven't yet taken the time to sort it out.
Quote:
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...
Bregalad wrote:
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.
Bregalad wrote:
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"?
Quote:
hould 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"?
God, no please no ! (it's already enough a huge mess like that !)
Quote:
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."
In this case, yes. But you'd note that,
technically there is absolutely no mention of "AOROM" anywhere on the hardware, so this game is not AOROM, not even AxROM.
Also, you'd note that the Japanese version of Deadly Towers has a "PCB Class : IREM-BNROM", despite the fact the game was released before the term "BNROM" even existed (as only the american Deadly Towers, released one year later, ever had this name printed on it's PCB).
Calling it "mapper #34" is also wrong because of the confusion with the NINA, so there is no proper and technically correct name for calling the Deadly Towers' mapper, period.
(don't say me that the Nintendo name as the priority, either, because the american version of "Batman : Return of the Joker" does not have a PCB class of "SUNSOFT-JSROM", which would be it's name following this logic)
I know I'm being an asshole, and I probably myself bring the confusion between circuit boards and mappers, as everyone on this board do. However,
technically this is wrong, I'm just trying to point it out. Now I don't know too much what is good for the wiki.
How about:
A mapper is referred to by (in order of highest to lowest priority): ASIC designation, board designation, game or company name.
If there's an ASIC mapper, the ASIC designation is used. If there's no clear ASIC designation, or the mapper is discrete, the board name is used. If the board name is unclear or unknown, the game name, or the company which produced the game and/or cartridge is used, and if even that is unknown or unclear, the mapper should default to the name "That Goddamn Unnameable Mapper Nobody Likes".
In the case of ASICs, there's hypothetically an unlimited amount of hacks you can apply to the base mapper, so for example, "MMC3" should always refer to the MMC3 as it is canonically intended to be used, and "modified MMC3" can be used for things like TxSROM.
A similar convention can be used for discrete mappers whose functionality is virtually identical to "official" discrete mappers. So if somebody used a GxROM, but with additional circuitry for software-controlled lockout defeat, it can be called a "modified GxROM", or it can be named after the company that used it, like Color Dreams.
Lastly, mappers are never referred to by their ines mapper number.
There exist more than one "modified MMC3". There's TxSROM, which runs CHR A17 out to CIRAM A10, and TQROM, which uses CHR A16 to
switch between a ROM and a RAM. There are multicart variants, which typically get the "game" name. And there are plenty of
variants on the Namco 108 theme. That's why I'm tempted to keep board names for unusual applications of at least Nintendo ASIC mappers.
Given that the Namco 108 variants have PCB names as memorable as "3453" and "3446", I don't really see an argument that those names would be more memorable, discoverable, distinguishable amongst themselves, or useful for reference than a mapper number.
I'd just say refer to the thing you're talking to by the most specific name that applies. This goes back to the principle stated early that we should avoid confusing iNES mappers (software) with boards or ASICs (hardware)
If you're talking about a BNROM/NINA-001 combo implementation, you should say mapper 34. If you're talking about the board used by Impossible Mission 2, say NINA-001. Where there are multiple names, use your judgement, e.g. VRC6a is probably preferred to 351951. If you're really uncertain, ask! I'm sure we'll have five different opinions ready for you.
Mapper 7 and AxROM happen to be synonyms, since AxROM is not a board name but rather a name we (Disch?) chose for a class of boards, all of which are supported by mapper 7. To me, AxROM is the more memorable and commonly used name.
Similarly, if talking about game that uses oversized BNROM (I'm making one at the moment), I'd follow Disch's guideline and call that BxROM, since BNROM is a specific board that doesn't support large sizes, and mapper 34 is a stupid combination of two unrelated board emulations.
These are just examples, I don't think we need to attempt a one-size-fits-all rule here; there's a lot of crazy stuff going on in the organization of mapper/board emulation, and we need to think carefully about the appropriate terms as we use them.
Quote:
Mapper 7 and AxROM happen to be synonyms, since AxROM is not a board name but rather a name we (Disch?) chose for a class of boards, all of which are supported by mapper 7. To me, AxROM is the more memorable and commonly used name.
I was under the impression AxROM was a name to refer all Nintendo made boards that starts in 'A' and ends in 'ROM'. In that case that would be ANROM, AN1ROM, AMROM, AOROM and perhaps some other obscure prototypes boards. This would not include the american Wizards & Warriors III, nor any mapper #7 homebrew.
That's just what I logically assumed, since SxROM and TxROM respectively are all baords using MMC1 and MMC3, no matter which mapper they are (TLSROM belongs to TxROM despite not being mapper #3).
Even if this naming convention were to be adopted (why not after all, despite being a little confusing), then how should mapper #3 be called ? CxROM ? But then what about CPROM which implements a totally unrelated mapper ?
CPROM, TxSROM, and TQROM get "more specific" names because they have different behavior. But "totally unrelated" is stretching it, as the behavior is a small change to the "parent" board. CPROM is CNROM with a fixed bank, TxSROM is TxROM with CHR A17-controlled nametable mirroring, and TQROM is TxROM with CHR A16 switching between two different memories.
Yes, if you're looking only from a SW point of view, mapper #12 is like mapper #3 with a fixed bank and CHR-RAM instead of CHR-ROM, which may effectively not be "totally unrelated" but "quite unrelated".
Were developers offered to have a fixed CHR bank, but with CHR-ROM ?
I think most of the confusion would be cleared up if we somehow could figure what official nintendo developers were "offered" and their viewpoint of the situation (I mean, without the iNES point of view, nor the hardware/boards point of view).
Bregalad wrote:
Even if this naming convention were to be adopted (why not after all, despite being a little confusing), then how should mapper #3 be called ? CxROM ? But then what about CPROM which implements a totally unrelated mapper ?
I'm not really interested in adopting any conventions. I just want to move forward using the terms as they already exist.
Yes, AxROM works for the actual A*ROM boards, and since the acclaim board and other boards you mentioned are transparently identical to AxROM there really isn't any confusion about the function of these boards if you refer to them as AxROM.
If you know using CxROM to describe CPROM is wrong, don't use the term CxROM that way. Use it only where you can make the meaning clear. Don't worry about establishing a convention for "xROM" terminology, boards and mappers aren't organized enough to have rules like this. It's not a periodic table.