Talk:Mirroring

PAxx vs. PPU Axx vs. CHR Axx

These edits by infiniteneslives confuse me a bit. I've seen "CHR A10" and "CHR A11" used for the lines going to the CHR ROM. In ASIC mappers, these tend not to match PPU A10 (PA10 for short) and PPU A11 (PA11). --Tepples (talk) 12:04, 23 February 2013 (MST)

"L" mirroring

Using a single and-or-invert gate, or three NAND or NOR gates, along with two bits from a latch gets you controllable 1/H/V/L mirroring. This is roughly what mapper 243 does. —Lidnariq (talk) 00:32, 4 May 2013 (MDT)

4-screen capable mappers

lidnariq wrote here:

None of MMC3, MMC5, m77, nor m99 "are capable of mapping some of their CHR[...] into the nametable space". The question of CHR as nametables is largely orthogonal to 4-screen layout; I don't think it belongs here.

I think any mapper that can map 4 different 1k pages into the 4 nametable regions is relevant to 4-screen mirroring (this is what I consider the definition of 4-screen mirroring). Why don't you think they belong there?

• MMC3 - Rad Racer 2.
• MMC5 - Using fill-mode as a 4th nametable qualifies, I think, but is very limited.
• VRC6 - Lets you map CHR-ROM into nametable pages arbitrarily. (Not sure if any games do it.)
• Namco 163 - Lets you map CHR-ROM into nametable pages arbitrarily. (See Final Lap.)
• iNES Mapper 077 - Uses combination of VRAM and CHR-RAM to create 4 RAM nametables. (Napoleon Senki)
• iNES Mapper 099 - Not sure why this became a mapper, but as described I don't see why it doesn't qualify as 4-screen capable?

- Rainwarrior (talk) 10:42, 14 May 2015 (MDT)

The sentence discusses mapping some of their CHR into the nametable space. Which is false for four of the examples, and orthogonal to how four-screen mirroring works. If rephrased to instead be what actually belongs in the section ("allows treating nametable address space as a 64x60 tile map") it's then redundant with the surrounding text. (MMC5 supports three real nametables and a fourth where all 960 locations are the same tile and same attribute... which I personally wouldn't count here) —Lidnariq (talk) 10:58, 14 May 2015 (MDT)

I don't think it's orthogonal at all! What do you mean by this? Mapping CHR-RAM or CHR-ROM into the nametable space is one way of implementing 4-screen mirroring. I've separated MMC5 and the Vs mapper. VRC6, N163, and 77 all map their CHR-RAM or ROM chips directly into the nametable space, so I don't know which four examples you think are false; at most it would just be MMC3? I thought Rad Racer 2 mapped CHR-ROM as nametables, but I would have to check again. - Rainwarrior (talk) 11:07, 14 May 2015 (MDT)

CHR is stored on memory. Memory itself is not CHR. That Napoleon Senki uses one 8 KiB RAM that's used for both two nametables and for 6 KiB of CHR-RAM doesn't mean that the CHR is mapped into the nametables. Additionally, I say it's orthogonal because you don't mention JY Company or Sunsoft 4 in this section (but instead mention them in the "other" section).

If you replace "CHR" with "on-cartridge PPU memory" then this specific sentence is redundant with the surrounding text: "MMC3" is redundant with "Add a 6264 8 KB RAM on the board. CIRAM /CE is pulled high, and the cartridge RAM is enabled at $2000-$3FFF. The PPU itself never uses $3000-$3FFF during rendering, but 8 KB RAMs are easier to find than 4 KB RAMs.". The missing "MIMIC-1" is redundant with "Add an extra 2 KB of RAM on the board. Decoder logic enables CIRAM only for $2000-$27FF and the cartridge RAM $2800-$2FFF.". Mapper 77 is repeated in the list below. —Lidnariq (talk) 11:18, 14 May 2015 (MDT)

Okay, so what I was really hoping to provide was a list of mappers that can do 4-screen mirroring, and a brief description of each. I've reorganized them into a bulleted list in this way, and I hope this obviates the problem you had with the sentence as it was. What is MIMIC-1, should it be on the list? (I can't seem to find info on it in the Wiki.) - Rainwarrior (talk) 11:28, 14 May 2015 (MDT)

Yes, this solves my complaint. Thanks!

MIMIC-1 was Tengen's rebadged Namco 108, so it's redundant with the m206 mention. Might want to figure out how to rephrase the Vs. System bullet too, because the mappers used with it intrinsically had 4-screen layout, not just m99. Tangenting: No VRC6 games used 4-screen layout (let alone ROM nametables); apparently no m211 (JY Company) did either. But the hardware certainly supports it... —Lidnariq (talk) 11:43, 14 May 2015 (MDT)

The only mapper *not* capable of 4-screen mirroring I can think of is MMC5. All the others are capable of it by adding an additional chip on the cartridge (or two). The fact very few games used this is a different matter. Also, the ROM nametables have absolutely nothing to do with 4-screen mirroring, it's two completely different things. When we talk about "Nametable mirroring", we normally have RAM in mind, ROM is a very rare and particular case that is its own weird beast.Bregalad (talk) 11:31, 14 May 2015 (MDT)

Whether nametables are ROM or RAM is important, and related, but it's not "mirroring" at all. Extra nametable RAM is its own thing, separate from mirroring, but it's generally very important how it is combined with it. We need to cover both here. (Also, with the iNES 2 format, it becomes an arbitrary choice for VRC6/N163.) Both cases are pretty rare; you're arguing that 3 games is less rare than 2? This is not a case where one is an edge case and the other dominates. (They are all edge cases.) - Rainwarrior (talk) 11:40, 14 May 2015 (MDT)

I like your point that any mapper can do 4-screen RAM, though. I added an entry noting that it's available as an iNES header flag, and I think the hardware how-to covers the case of actually adding it to a board that didn't have it. I think the rest of the list is important because these are the only boards you will find ready for 4-screen, just like it's important to know which boards would normally be set up for CHR-RAM and not CHR-ROM. - Rainwarrior (talk) 11:51, 14 May 2015 (MDT)

Man what happened to my mirroring chart!

Back when I created this, the idea was to have a quick and simple overview though the different basic mirroring/scrolling combinations, letting the reader adult enough to understand this on his own and extend this to whatever he feels.

Someone apparently turned it into the current monstrosity that attempts to document every single mirroring/scrolling combination ever possible with NES hardware, including many which were never used by any games or not even homebrew tech demoes (I think especially of the so called "3-screen mirroring" here). This is downright ridiculous, and it lost its original sense of the very reason why I created this chart back then.Bregalad (talk) 01:55, 15 May 2015 (MDT)

Once, including a commercial games, it will be helpful for the production of one of homebrew games.--PGCX864 (talk) 07:57, 15 May 2015 (MDT)

It's not currently helpful at all. I'm sorry. What you seem to be doing is trying to categorize everything you can find; this is very different than providing a helpful guide! Right now you have 4 columns (status bar, parallax, etc.) and 11 categories; that's 44 different cases you are throwing at the reader? Someone who is struggling to understand mirroring will have no idea how to pick from this or figure out what they need from it. This chart isn't even much use for someone who knows how mirroring works already.

If you want to categorize every game in existence by how they do rendering and their mirroring approach, that might be okay on its own article page, like how we have things like List of games with expansion audio or Sprite overflow games, but what you're doing now is too much information (or maybe just too poorly organized) for this article about Mirroring. Maybe List of games by mirroring technique? Perhaps reference like that organized in one place would be useful to somebody, and we can just link to it from this mirroring article. Just leave a small handful of useful/common examples here, the initial grid was supposed to be a tutorial and quick summary. - Rainwarrior (talk) 09:50, 15 May 2015 (MDT)

To explain what I mean about it not being helpful. Think of what you need to know about mirroring and NES rendering to understand how to implement having a status bar on the top or bottom. Mirroring and NES rendering is not something you can just look up in a chart and pick an answer. Nobody's going to be able to make Guardian Legend or After Burner after reading that chart, they have to understand a lot more about rendering, not just mirroring. The mirroring teaches you next to nothing about how those games' rendering works. What we want to do in a tutorial is illustrate how mirroring works with a few easy to understand examples. - Rainwarrior (talk) 10:02, 15 May 2015 (MDT)

Another way of thinking about this: if Battletoads can do 2D scrolling with a status bar, using only single screen mirroring and no IRQ, really you can do any scrolling method with any mirroring, if you want to work hard enough for it. The short of it is that for 1D scrolling, there are a few choices that make it easy (horizontal, vertical, metroid), and there's no turnkey solution for 2D scrolling but we can make a few good suggestions (like to look at SMB3), but beyond that the solutions are very game-specific and tricky, far too detailed to summarize here, and you can do it 1000 different ways (each of which would need a whole article to properly explain). Hmm, this is pretty much exactly what the chart already expressed before PGCX864 started adding to it: revision 8215. I think there's use for a comprehensive catalogue of which games use which mirroring techniques, but it doesn't belong in this article. - Rainwarrior (talk) 23:53, 16 May 2015 (MDT)

That revision is way better, but is still too much because it mention the never-used L shaped and diagonal mirroring. I do not think there is a need to document the list of mirroring/scrolling combinations all games uses, this is almost endless and each game is specific. If you are interested about a particular game, just look at an emu with a NT viewer, it's always interesting. There's even less need to document every unused mirroring/scrolling combination we could ever think off. Personally, as the creator of this mirroring char back then I believe it's purpose has been completely misunderstood and that, with the distance, I can see this chart was never very useful. I believe removing it completely is probably the best option. The animation on the SMB scrolling article is probably a better approach at documenting the thing.Bregalad (talk) 06:46, 17 May 2015 (MDT)

This revision [1] is probably how this page should have stayed, without those ugly image with barely readable letters Bregalad (talk) 06:58, 17 May 2015 (MDT)

I've made an attempt to rebuild the table with just the simple/straightforward techniques, and I've moved the monster table over to List of games by mirroring technique, which will need some organizational work but I think might make a good start for a nice survey of the advanced techniques out there. - Rainwarrior (talk) 17:00, 17 May 2015 (MDT)

Thank you Rainwarrior, it is much better now. The table makes sense again. However, there is just a little tiny weakness. It says Horizontal mirroring makes it difficult to use a status bar. Taken like this without any additional information it is hard to understand why. I'd suggest replacing it with Vertical scrolling makes it tougher to use a status bar. This has the advantage of being more exact:

1. Vertical scrolling makes it tougher because you have to use $2006 as well as $2005

2. Vertical scrolling makes it tougher because you need to plan carefully where the status bar and playfield will go in VRAM (no matter the mirroring)

3. The use of thougher makes it clear it's still perfectly possible and reasonable, the use of difficult makes it sounds like it's not a reasonable choice.

Also, why the wiki links for status bar? Is there an intention to create a status bar page later?Bregalad (talk) 03:19, 18 May 2015 (MDT)

Well, the reason I said "horizontal mirroring" and not "vertical scrolling" is that if you do vertical scrolling with a different type of mirroring (e.g. single screen) it's a lot easier to make a status bar. It seems to me that it's specifically horizontal mirroring that causes the problem, mostly because of how to lay out the nametables so you can scroll split to it. I don't think of having to use $2006 is tougher, we have a simple recipe for that and it doesn't require compromises or extra planning. There's no recipe for the nametable layout problem, though- you have to do something special to get around it. Every game I can think of that has horizontal mirroring + a status bar had to do something pretty advanced. SMB3 and Jaws get around the problem by limiting Y scroll. Crystalis has 2 splits requiring an IRQ. Can you think of any others? I can think of a lot of games that have vertical scrolling and status bars, but I'm having a hard time finding any others that use horizontal mirroring. Also, yes I figure status bar should have its own article eventually, just leaving a redlink as a reminder of that. - Rainwarrior (talk) 11:41, 18 May 2015 (MDT)

I think there was also a scrolling tech demo a while back (can't find it at the moment) that relocated the status bar in the nametable every few frames, but again this is a really advanced thing to do! The Hiatus Ward demo also had horizontal mirroring, Crystalis style. - Rainwarrior (talk) 11:49, 18 May 2015 (MDT)

Well, you are correct, but vertical scrolling + status bar + vertical mirroring is likely even more difficult. Jungle Book and Krusty's Fun House does that (using 2 radically different techniques). Single-screen mirroring is the only "easy" way to have free-bidectional with status bar. As for $2006, you are correct it is not a problem today, but it appears that when the NES was released it took time for the developpers to start using this trick, it wasn't used before Zelda I believe. Using it for a status bar at the top is harder, but if the status bar is at the bottom it makes it harder to combine with a sprite zero hit on a unknown playfield, and to combine with gameplay's program. With IRQ capable mapper it's no problem indeed. Not related, but you should look into Kirby's Adventure, Double Dragon series, Gradius II and Gargoyle's Quest if you are interested in games with free-directional scrolling with horizontal mirroring and status bar. (neededless to say, all uses radically different techniques).Bregalad (talk) 12:30, 18 May 2015 (MDT)

Both single screen and horizontal mirroring is perfect for vertical-only scrolling with a status bar. Glitches hidden by the bar, easy to implement, etc. I don't know any games that do it, though, I've only seen it with 2D scrolling. An example would be good, but maybe this is what should be said in the chart. - Rainwarrior (talk) 13:43, 18 May 2015 (MDT)

Oh yeah, you are right (assuming you meant vertical mirroring), Life force does that in it's even levels, and Guardian force in spaceship shooter mode for example. It's hard to word what exactly is "difficult", and it's completely subjective after all. The only really difficult part is to "get the trick done", and even in the worst case it's still not the most difficult part of writing a complete working game.Bregalad (talk) 01:21, 19 May 2015 (MDT)

Explaining this reversion: 10848 - Limited 2-screen (Gyromite, Wrecking Crew, etc.) I deliberately left out of the chart, because this is an issue of scrolling, not mirroring. The simple case for mirroring is exactly the same as if you are doing unlimited 1-axis scrolling. Mega Man does not actually use switching H/V, check it with a debugger. Zelda and Ducktales are also complicated. Just because these games do screen-locked scrolling doesn't mean they're doing it the naive way; the status bar especially throws a monkey wrench into it. - Rainwarrior (talk) 11:08, 19 May 2015 (MDT)

Mirroring images

Bregalad complained that he doesn't like the lettering on the mirroring images. I actually like them a lot, but I have my own bone to pick with them, which is the addressing on the side. The base address of each nametable is the most important address, and it only appears on the left side tables. Everything else is just noise, like the 24CF at the end of a row isn't helpful to anybody trying to learn. (It's clear what it is to someone who already understands nametables, but it's useless to that person.) Here's a proposal for a new style:

1. Removed the address columns in favour of larger embedded base addresses.
2. More standard lettering.

Any thoughts about it? - Rainwarrior (talk) 18:44, 17 May 2015 (MDT)

For me, it's way better.Bregalad (talk) 01:32, 18 May 2015 (MDT)

Finally got around to this. If the new style isn't to someone's liking feel free to take another crack at it. Here's the python program that generated the new set: pastebin link - Rainwarrior (talk) 01:26, 5 March 2017 (MST)

Games that depend on WRAM mirroring?

Apparently, there's 3, but no one can seem to remember them. They likely use a page# index and take advantage of ignoring higher bits and just increment infinite loop 0...FF without bothering to reset to 0 after 7, so go through 8-1F (ANDed with #$1F)? But that makes no sense as you could have just ANDed with #$07. Anyone know for sure what they did and why? alphamule (talk) 00:44, 15 February 2017 (MST)

Well, I intentionally used WRAM mirroring in Driar's NROM port to move the stack relative to the self-modifying code in RAM—Lidnariq (talk) 11:01, 15 February 2017 (MST)

MMC5 and "four screen memory"

Let's not have an edit war. If Bregalad wants to discuss this, we'll discuss this here. But until such time as we come to an agreement here, neither of us should edit the page.

Fact of the matter is, MMC5 does support four distinct renderable nametables at the same time. Arguing that it doesn't count because one is only 10 bits instead of 8160 doesn't change that it is a distinct thing. I just can't come up with any argument for why ROM nametables are allowed to count but the fill-mode nametable isn't. — Lidnariq (talk) 13:33, 4 March 2017 (MST)

I think fill mode counts, and it's fully disclosed by the description so I don't see anything misleading about having it in the list. - Rainwarrior (talk) 19:26, 4 March 2017 (MST)

Definition of 4-screen mirroring according to Rainwarrior on this very talk page :

I think any mapper that can map 4 different 1k pages into the 4 nametable regions is relevant to 4-screen mirroring
(this is what I consider the definition of 4-screen mirroring).

and acording to the wiki page

With additional RAM and/or PPU address mapping present on the cartridge, 4 unique nametables can be addressed through the PPU bus,
creating a 64x60 tilemap, allowing for more flexible screen layouts. Very few games made use of this type of mirroring.

MMC5 fits neither of those definitions. MMC5 supports 4 different modes for each nametable, but does not support 4-screen mirroring, even if each of the name tables is set to a different mode (leading to the 4 nametables having a different mode each) it won't work as the name table in the fill mode is not a 1k page of data, but a single repeated tile instead. This does not create a 64x60 tilemap. Bregalad (talk) 01:45, 5 March 2017 (MST)

I think it does fit the current definition in the wiki? It creates 4 different nametable pages. Yes one of them is a single repeated tile, but the important thing is that it's different from the other 3, and that since it's a strange case it should explain that (which it does). It's not like it just says "MMC5" in some misleading way, it explains the whole thing. - Rainwarrior (talk) 01:54, 5 March 2017 (MST)

Just because the fill-mode nametable is algorithmically generated instead of RAM doesn't mean that it's not a nametable. —Lidnariq (talk) 12:37, 5 March 2017 (MST)

I should say, though, that I think it's something that should be mentioned as an oddball case whether or not you think we should use a definition of 4-screen that is strictly exclusive or inclusive to it. It's s special case worthy of a special mention, IMO, and is related enough to 4-screen mirroring at any rate. If you think it's muddling the definition somehow or should be worded differently I'm open to suggestions, but my hope when I wrote the current wording was that it would be clear exactly what it is and isn't from reading it. - Rainwarrior (talk) 02:10, 5 March 2017 (MST)

We definitely agree MMC5 is a special case. In my opinion, the notion of "vertical" "horizontal" and "4-screen" mirroring only applies to regular mappers making regular use of VRAM. MMC5 is so weird it doesn't fall in any of those categories, this should be mentioned. The point of 4-screen mirroring is (mostly) to be able to scroll vertically and horizontally without updating nametables. MMC5 can't do that. The point of fill mode is not to have a 4th distinct nametable - but rather to have a repeated tile all across the screen - when Fill Mode is used, it's intented to be used for 4 screens at once. Using Fill Mode for just 1 screen and 3 nametables for the other 3 just doesn't make any sense - you couldn't scroll a video game level using that configuration. However it doesn't need to becase ExRAM is even more useful than 4-screen mirroring, for instance MMC5 allows glitch-free multidirectional scrolling thanks to mode #1 without the need for 4-screen mirroring. So the MMC5 is already extensively mentionned in the "other" paragraph:

Other uncommon types of mirroring are available in other boards, such as TxSROM variations of the MMC3, extended techniques available to the MMC5, 
arbitrary VRAM mirroring arrangements by the Namco 163, or ROM mirroring arrangements using mappers that allow ROM nametables.

There is no need to mention the MMC5 in the 4-screen mirroring paragraph, because 1) MMC5 does not support 4-screen mirroring and 2) it's already covered in the "other" paragraph where it is supposed to be, because it's where it fits. If information in "other" is lacking, then it should be extended there.

Bregalad (talk) 02:50, 6 March 2017 (MST)

Your argument why the fill-mode nametable doesn't count is equally applicable to ROM nametables. —Lidnariq (talk) 11:20, 6 March 2017 (MST)

Which argument exactly are you refering to ? ROM nametables is an entierely other thing - you could use that with either mirroring and even mix ROM and RAM nametables if this makes any sense. MMC5 supports neither ROM nametables nor 4-screen mirroring.Bregalad (talk) 11:51, 6 March 2017 (MST)

Your entire argument seems to boil down to ~the only possible purpose of 4-screen layout is to use it the exact way Gauntlet, Rad Racer 2, or Napoleon Senki do~, i.e. four independent not-remappable RAM nametables. But none of the other hardware listed in the section is used with a game that does that. And this section of the document isn't about "what do legacy games do" but rather "what hardware supports 4 simultaneous different 32x30 tilemaps in the 64x60 addressable space". —Lidnariq (talk) 12:54, 6 March 2017 (MST)

Exactly - and the MMC5 is perhaps the only Mapper who can't support 4 simultaneous different 32x30 tilemaps in the 64x60 addressable space. All other mappers can do that quite easily by adding RAM - but the MMC5 already tricks the PPU adress space in it's own way which is largely incompatible with the normal 4-screen mirroring configuration.Bregalad (talk) 05:51, 7 March 2017 (MST)

Please explain exactly how a fill-mode nametable is not "a simultaneous different 32x30 tilemap". Additionally, please explain or take a guess as to why there's a list of hardware on the page, if you think the only possible reason to talk about 4-screen layout is to use it in the exact way that Gauntlet, Rad Racer 2, or Napoleon Senki do. —Lidnariq (talk) 11:28, 7 March 2017 (MST)

Fill mode is a 1x1 tilemap, not 32x30. There's not 1k of data - there's just 1 byte. I do not understand what you mean in the second part starting with "please explain..."Bregalad (talk) 00:12, 8 March 2017 (MST)

Fill mode is a single tile that is filled over an entire 32x30 tilemap. If you set up the MMC5 to display four different simultaneous nametables, one of which is (necessarily) the fill-mode nametable, it is still displaying four different nametables. I can easily construct situations in which three corners of the 64x60 tilemap would have "real" data and the last one would be the fill-mode nametable and the game would scroll through showing all four nametables at the same time.

So, pray tell, what exactly is the correct description of the situation in which four different nametables are displayed onscreen simultaneously? —Lidnariq (talk) 11:34, 8 March 2017 (MST)

Fill mode is not a "name table" per se because there's no "table", just a single byte.Bregalad (talk) 00:54, 10 March 2017 (MST)

The PPU doesn't know how to render "a single byte". It knows what to do with a nametable and a pattern table.

Arguing that the fill-mode nametable isn't a nametable is to deny its function. To the PPU, it looks like a nametable, swims like a nametable, and quacks like a nametable, so how can you seriously argue that it isn't a nametable?

Just because it's entirely configured via a small number of register writes? So are ROM nametables!

Does it somehow magically become not a nametable just because it's configured to displayed next to three RAM nametables?

Or do you somehow disqualify it just because it's low entropy? Does cleared RAM not count as a nametable them? The PPU doesn't care about entropy; it just cares about nametables and pattern tables. —Lidnariq (talk) 12:02, 10 March 2017 (MST)

"Or do you somehow disqualify it just because it's low entropy?"

Yes, that's exactly what I do. You don't get a 32x30 tilemap with fill mode, instead you fill an area with a single byte. It's something entierely different that falls outside of the regular shemes of mirroring (be it single-screen, horizontal, vertical, or 4-screen). You could even call this "signle-tile mirroring" if you'd like.Bregalad (talk) 08:14, 11 March 2017 (MST)

Got it. Any time we instruct people to clear nametable memory, I will instead tell them to delete their nametables. And if there are any games with ROM nametables explicitly use a chunk of CHR-ROM that's all one byte as a nametable ... oh, wait, not a nametable, sorry ... I'll be sure to pedantically point out that those aren't nametables because they're low entropy.

Anyway, you've got three people who have voiced their disagreement with you, so don't make the edit.—Lidnariq (talk) 11:51, 11 March 2017 (MST)

"Using Fill Mode for just 1 screen and 3 nametables for the other 3 just doesn't make any sense - you couldn't scroll a video game level using that configuration."

Yes, you could:

Metroid's level and art design fit the bill. Myask (talk) 15:11, 6 March 2017 (MST)

Your example makes no sense. First the horizontal section is larger than 64 tiles, and the vertical section is higher than 60 tiles as well. So map scrolling has to be implemented to implement Metroid anyways. Also the fill mode nametable in your example is not displayed - so it could be anything and fill mode is not required. That's exactly what the real Metroid does - it switches between H and V mirroring depending on whether it's scrolling an horitzontal or vertical level. Neither 4-screen mirroring nor fill mode are required. And it's still a fact you can't scroll a 64x60 tile video game level using MMC5 fill mode - MMC5 does not support 4-screen mirroring.~~

The idea was that you'd scroll more like Megaman X (having certain sections where the scroll is locked to one direction, but allowing diagonal scroll when transitioning between them). The doors could be removed; if the player stepped to the right of the intersection, the game would attempt to scroll up to align Y-wise with that nametable while scrolling X; and likewise if going below the intersection screen, it would scroll to align X-wise while scrolling to follow motion with Y. It would remove the wait that e.g. Super Metroid imposes while it lines the door up to the middle of the screen. The map data is even in screen/NT-sized chunks. 4-screen/MMC5 are not required, no, but it is an example of how it could be used, as you asserted it wasn't. And, as you can't see through walls, even if two corridors were adjacent in a four-screen manner (which I don't think they generally are in Metroid 1, but don't care to check) the fourth nametable contains room data that the player-character could not see, so a blank NT would be diegetic.

And if you're asserting about my image being more than 60 tles tall rather than the greater map from which it is sampled, it isn't; 60*8=480. Myask (talk) 16:57, 7 March 2017 (MST)

Yes, this is indeed a nice example of usage of fill-mode. This isn't 4-screen mirroring though.Bregalad (talk) 00:12, 8 March 2017 (MST)

To be honest, I think the term "mirroring" is a confusing way to describe nametable memory layouts. Even on Nintendo's boards "H" means "vertical mirroring" and "V" means "horizontal mirroring"-- clearly they though about it in the more natural/intuitive "horizontal arrangement" / "vertical arrangement" concept. This seems analogous to Pi vs Tau, where a less convenient version became popular and entrenched. Personally I would have preferred if "horizontal mirroring" meant vertical wrapping (even though the actual "mirrored" pages are arranged horizontally from each other). I don't know who made this terminology popular, probably Marat when he established the iNES format? 4-screen, of course, is a complete lack of "mirroring", in the hardware sense, but over time we seem to have ended up using the term "mirroring" for all arrangements of the nametable memory, and it doesn't specifically mean mirrored memory in that context.

Anyhow, I'm saying all of this merely to acknowledge that mirroring is confusing terminology. I do think it's the standard terminology, though, and we should be consistent with the way it is used and what it normally means in this specific NES context. 4-screen is a "nametable mirroring mode", even if the etymology is stupid/broken. I don't want to argue what mirroring should mean, what's important to me is what it does mean. (I don't want to see this wiki text become a place full of internally-consistent jargon, where only the initiated know what words are supposed to mean.)

What we're trying to describe in this article is different ways nametable memory can be arranged, which is unfortunately colloquially called "mirroring". The piece of the article in question is trying to be a inclusive list of all mappers that can do 4 screens in a special way, no matter how marginal that ability it is. MMC5 belongs with the others, in this respect. There's no deception or ambiguity about the description of this MMC5 possibility, the article fully qualifies that the fourth page is blank. - Rainwarrior (talk) 13:44, 11 March 2017 (MST)

I agree with pretty much all you've said there. "Mirroring" is an unfortunate term derived from iNES. The original iNES format allowed only horizontal, vertical and 4-screen mirroring, but any mapper would supplant those and come up with it's own system. MMC5 is different that all default iNES configuration, and should me mentionned as such (actually it is). What I specifically don't like about this page as it currently is (13 march) is that it's a major "don't repeat yourself" failure - MMC5 is mentionned twice, as well as other thigns. The page is desesperately over-complicated, going into details that should, IMO, belong to the respective mapper's page and not here. (most of the time the info is already here at the mapper's page). It seems you guys sometimes wants to fill the wiki with as much text as possible.Bregalad (talk) 08:40, 13 March 2017 (MDT)

I could possibly be persuaded that there is a reason to elide the entire 4-screen layout section and fold its content into the "other" section... very few games used the static unbanked 4-screen layout, even though it was always available on the Vs. System; especially in comparison to the number of games that used H/V/1. —Lidnariq (talk) 17:21, 13 March 2017 (MDT)

I don't know... The problem is that 4-screen mirroring is part of the iNES header, so this makes this layout "important" even if few games used it. And I just noted our whole argument were completely pointless... the list title says : "Mappers already used in combination with 4-screen mirroring:" (i.e. configurations that games actually used). I don't think any MMC5 commercial games ever used fill mode, let alone with 3 other nametables simultaneously, so... it shouldn't be on this list, no matter whether this "counts" as 4-screen mirroring or not. The mappers using ROM nametables also shouldn't be on this list, exept the Namco (since it's the only mapper where games actually seems to have used ROM nametables with 4 different nametables simultaneously). In fact, my personal opinion is that such a list is pointless... just mentionning that almost all mappers are capable of 4-screen mirroring theoretically but that this was extremely rarely needed would be sufficient for me.Bregalad (talk) 01:51, 15 March 2017 (MDT)

That's my point. Once we shave down the set of games to just the ones that use 4-screen layout in the very narrow way that you describe, there aren't really enough of them to warrant a whole subsection. It's just one more rarely-used way to handle the 4 KiB of address space for nametables. —Lidnariq (talk) 13:06, 15 March 2017 (MDT)

What if I just separate the 2 mappers that are theoretical exceptions from the list of ones that we have game examples for? Does that description look better? - Rainwarrior (talk) 18:36, 15 March 2017 (MDT)

It is indeed better, however I still think the page is largely improvable, but cannot see how exactly. It is kind of messy and does long ridiculously long explanations and lists of games for what is actually extremely simple concepts. As I said before, people just want to insert as many informations as possible, even if this is mid-relevant. (For example list of gamaes using any feature do normally not belong to a page explaining the feature, in my opinion).Bregalad (talk) 01:52, 16 March 2017 (MDT)

Definition of "Four screen" according to the glossary in this very wiki :

A mapping of cartridge memory to the PPU bus that expands the memory available for nametables to 4K, thus allowing four distinct nametables.

Notice how 4K memory is explicitly mentioned - exactly my point all along - MMC5 has 3K of nametable memory not 4K.Bregalad (talk) 02:43, 29 March 2017 (MDT)

Would you object to a revision of that glossary entry that didn't use that particular definition? - Rainwarrior (talk) 19:05, 29 March 2017 (MDT)

Castlevania 3

The article claims (since March 2010) that "Castlevania 3 uses the third nametable RAM available on the MMC5". Given that the Japanese version did not have 3 nametables at its disposal, I find this claim to be highly suspect - exactly where in the game is ExRAM used as a nametable? --Quietust (talk) 07:34, 5 March 2017 (MST)

I just searched through the entire game data; the game seems to reliably copy ZP $25 to $5105 in the NMI, and it seems to always set that using LDA #im / STA $25. The only immediate bytes I found were $44, $50, and $55. Seems likely that that's wrong... —Lidnariq (talk) 13:06, 5 March 2017 (MST)

It's used in the Aquarius level where the water rises - the difference between the VRC6 version and MMC5 version is major here. In the japanese version, the game switch to horizontal mirroring, enables left-8 column hide and has a glitchy scrolling for that part. The MMC5 version uses the 3rd nametable for the rising water and leaves the mirroring and scrolling engine to normal operation, resulting in clean scrolling.Bregalad (talk) 02:45, 6 March 2017 (MST)

So in this area we have horizontal scrolling + a rising water overlay. (I made an image to show it so the description on the wiki will be less mysterious.) The VRC6 version accepted errors at the edges and just used vertical arrangement instead? Since the water is an unmoving screen, I wonder if they could have just used the ROM nametable feature of the VRC6 for it? (As an aside, were there any uses of ROM nametables on VRC6?) - Rainwarrior (talk) 19:23, 15 March 2017 (MDT)

I haven't looked it up but if I were the coder I'd never use the ROM nametable for such a feature. The whole screen is basically several repeated water tiles, wasting 1k to store that repeated data seems unoptimal when you could write a simple loop that writes this to RAM. Actually, only screens with incompressible data on them would be worthy of ROM nametables.Bregalad (talk) 01:49, 16 March 2017 (MDT)

Funnily enough, the last 1k CHR-ROM page is all 0s anyway, so they had apparently wasted 1k to store nothing instead. ;) This of course requires the hindsight to know they weren't going to need it though. - Rainwarrior (talk) 17:34, 16 March 2017 (MDT)

It's not "wasted" (per se) they use this page it for sections of vertical scrolling to disable BG display on some scanlines. (Of couse they could have done this through $2001 but for some reason they didn't - probably tradition as this couldn't be done on the MMC3 without screwing the scanline counter operation).Bregalad (talk) 06:44, 17 March 2017 (MDT)