So I know what mirroring is, but I don't know how I set it. There isn't a bit in the PPU control registers to set the mirroring, and when I went the nesdev wiki page, it says that vertical mirroring is in address $2000 and $2800, while as vertical is in $2000 and $2400. They say that mirroring exists because the NES didn't have enough PPU memory to have 4 screens, well why is there addresses, $2000, $2400, $2800. and $2C00, seems like it has enough memory to me. It says it has something to do with mappers. Well, if it involves mappers, then how come Super Mario Bros. can have Vertical Mirroring even though it doesn't have a mapper? You might not know what I'm referring to, so let me explain. on the wiki, it says "To configure a cartridge board for horizontal mirroring, connect PPU A11 to CIRAM A10. On cartridge boards made by Nintendo, this is selected by shorting the "V" solder pad (for "vertical arrangement"). Note using inverse logic may make more sense, "Leaving the 'H' jumper open gives horizontal mirroring" on Nintendo boards."
Well if this is the case, then how come games like Metroid or Super Mario Bros. 2 switch mirroring modes on the fly?
Just because an address exists, that doesn't mean the memory it points to is visible ONLY at that address. Another example of memory mirroring on the NES is the CPU RAM, which is only 2KB, but can be seen at 4 different address ranges: $0000-$07ff, $0800-$0fff, $1000-$17ff and $1fff.
The PPU can see 4 name table slots, but the internal RAM chip for name tables only has enough actual space for 2, which can be arranged in different ways depending on configurations made inside the cartridge. These configurations may be hardwired (i.e. permanently soldered) or dynamically controlled by mapper chips.
The cartridge connector was designed to give a lot of control over the name tables to the cartridge, meaning that there are enough signals there to control which name table is mapped where and even to provide extra memory for a total of 4 unique name tables, so that no mirroring is necessary.
The mapper is switching H or V at runtime based on what values the CPU writes to its ports.
Metroid (メトロイド),
Super Mario Bros. 2, and
Doki Doki Panic are for the Famicom Disk System. This mapper contains a 2-to-1
multiplexer controlled by
bit 3 of $4025, which selects PA10 or PA11 to be routed to A10 of nametable memory.
Metroid and
Doki Doki Panic changes the value of this bit when Samus goes through a doorway or Papa enters or leaves a vertical level, be it through a door or a ladder. (
SMB2 doesn't change it.)
Metroid (U) is for the MMC1. This mapper contains a 4-to-1 multiplexer controlled by
bits 1-0 of $8000, which select a constant 0, a constant 1, PA10, or PA11 to be routed to A10 of nametable memory. It changes the value of this bit every time Samus goes through a doorway.
Super Mario Bros. 2: Mario Madness (also called
Super Mario USA) is a port of
Doki Doki Panic to the MMC3. This mapper contains a 2-to-1 multiplexer controlled by
bit 0 of $A000, which selects PA10 or PA11 to be routed to A10 of nametable memory. It changes the value of this bit when Toad enters or leaves a vertical level, be it through a door or a ladder.
The MMC3's multiplexer follows this truth table:
Code:
Select PA11 PA10 | Out
0 0 0 | 0
0 0 1 | 1
0 1 0 | 0
0 1 1 | 1
1 0 0 | 0
1 0 1 | 0
1 1 0 | 1
1 1 1 | 1
Written more compactly using "don't care" notation:
Code:
Select PA11 PA10 | Out
0 x 0 | 0
0 x 1 | 1
1 0 x | 0
1 1 x | 1
The multiplexer in MMC1 and
Action 53 follows this truth table:
Code:
Select PA11 PA10 | Out
00 x x | 0
01 x x | 1
10 x 0 | 0
10 x 1 | 1
11 0 x | 0
11 1 x | 1
Okay, but how would a simple game with no mapper set mirroring, like Super Mario Bros.
If there's no mapper, the mirroring is set using solder pads that hardwire PA10 or PA11 to A10 in. You set the mirroring by bridging one pair of pads and not bridging the other pair.
DementedPurple wrote:
Okay, but how would a simple game with no mapper set mirroring, like Super Mario Bros.
Simply put, you can't from the perspective of your game's code.
You can select H/V mirroring in you ines header which tells the emulator what mirroring your cart has. That's something you decide at compile time.
You'll need a mapper if you want to change mirroring at run time.
DementedPurple wrote:
So I know what mirroring is, but I don't know how I set it. There isn't a bit in the PPU control registers to set the mirroring, and when I went the nesdev wiki page, it says that vertical mirroring is in address $2000 and $2800, while as vertical is in $2000 and $2400.
The current wiki page on mirroring is awful, and my attempts to revise it (to be still mediocre but less awful) were repeatedly rejected, so I gave up on the matter.
What does matter is that the wiki is a terrible ressource when it comes to this - the diagrams however should be helpful in understanding it. Other than that your best bet is to play games with nametable viewers enabled and see what is going on.
Bregalad wrote:
The current wiki page on mirroring is awful, and my attempts to revise it (to be still mediocre but less awful) were repeatedly rejected, so I gave up on the matter.
I encourage you to propose a fork in your own user space. Or did you and did I miss it?
Also I think the term "mirroring" have always been confusing in itself. Who cares what's mirrored when it's where the nametables are when scrolling that's the interesting part. Also using a term that is opposite from what Nintendo's boards and documents use (V-mirroring is H-scroll and H-mirroring is V-scroll) isn't very intuitive either.
Except a lot of games use horizontal scrolling with horizontal mirroring, such as Super Mario Bros. 3. That's why I've tried to use the term "vertical arrangement" to represent the $2000/$2800 layout where the nametable is 32 cells wide and 60 cells tall.
tepples wrote:
Bregalad wrote:
The current wiki page on mirroring is awful, and my attempts to revise it (to be still mediocre but less awful) were repeatedly rejected, so I gave up on the matter.
I encourage you to propose a fork in your own user space. Or did you and did I miss it?
He did, and you missed it (despite commenting in its discussion thread, somehow). Here's the discussion if you want to comment:
http://wiki.nesdev.com/w/index.php/Talk:Mirroring#Moving_the_bulk_of_scrolling_update_problems_to_scrolling_page
tepples wrote:
Except a lot of games use horizontal scrolling with horizontal mirroring, such as Super Mario Bros. 3. That's why I've tried to use the term "vertical arrangement" to represent the $2000/$2800 layout where the nametable is 32 cells wide and 60 cells tall.
Well H-scroll obviously doesn't mean that the game must scroll horizontally, but that horizontal scrolling takes you into the second nametable instead of mirrored VRAM. I say call it scroll mapping or nametable arrangement, either is fine, but mirroring is just backwards. Although it might be a bit late to change a convention like that.
That's why I tried to describe both the arrangement terminology and the mirroring terminology in the "awful" page on the wiki.
Changing the convention at this point may indeed end up causing even more confusion.
I don't understand how anyone in their right mind, dumping ROMs and looking directly at the "H" and "V" markings on the boards, would come up with the "mirroring" notation instead. I mean, the guy who invented the iNES format must have reverse engineered a couple of boards at some point in order to figure out what kind of information the header would need, right?
tepples wrote:
I encourage you to propose a fork in your own user space. Or did you and did I miss it?
I did exactly that but eventually I lost interest because the whole topic is a whole mess anyway. As already pointed out the "mirroring" terminology is already bad for vertical or horizontal mirroring, and becomes awful for describing anything else. My personal taste goes for the "arrangement" or "tilemap" terminology, but since the tile maps are not continious the arrangement terminology is the best. Saying a "64x30" tilemap seems to imply a row of continuous 64 characters, which is not the case when vertical mirroring is used.
In addition to that the term confuses mapper controlled and hardwired mirroring, which are two entirely different things hardware wise. That's why in my opinion when a MMC1 is configured to have, say, "vertical mirroring" it is not actual vertical mirroring but an emulation of vertical mirroring because the MMC1 controls the pin and it is not hard-wired. But other people refused to agree with me on this one, so it only brings more confusion to say mapper controlled mirroring can also be horizontal and vertical mirroring when it is in fact completely different than true hard-wired mirroring.
And I'm not even starting on iNES format which has complicated support for this. What a mess.
I'm not sure what you mean by specifying mirroring for MMC1 if you are not talking about the header.
In the Nintendo header you specify nametable arrangement as 0: H-scroll or mapper controlled, 1: V-scroll. But iNES reverses this. Speaking of that, what are you supposed to set mirroring bit if you are using a mapper that controls it or 4-screen in the iNES/NES 2.0 header? I'd guess just leave it at 0 (which would be opposite from the Nintendo header).
If the 4-screen bit is set, mirroring will be ignored (it can be 1 or 0) in both iNES and NES 2.0 format. Changes due to format occurs first at byte 8, whereas mirroring is set at byte 6.
When something is "don't care" it's usually set to 0 I think, so that's probably what I would set it if using 4-screen.
But what about using a mapper like MMC1 then? It's also "don't care"?
On most ASIC mappers (MMC*, FME-7), the mirroring bit is indeed a don't care.
I see, I think the wiki wasn't entirely clear on this. Also I still don't get what Bregalad meant.
Quote:
That's why in my opinion when a MMC1 is configured to have, say, "vertical mirroring" it is not actual vertical mirroring but an emulation of vertical mirroring because the MMC1 controls the pin and it is not hard-wired.
The VRAM/CIRAM is mirrored in exactly the same way regardless of whether VRAM/CIRAM A10 is controlled by a copper trace or a logic gate. To call that emulation is misuse of the word IMO. The signal source is still the PPU's A10/11 address pin, buffering the signal in a gate vs a copper trace doesn't make it emulation.
I can see why wording like this is confusing to someone who doesn't fully grasp nametable mirroring/arrangement.
infiniteneslives wrote:
The VRAM/CIRAM is mirrored in exactly the same way regardless of whether VRAM/CIRAM A10 is controlled by a copper trace or a logic gate. To call that emulation is misuse of the word IMO. The signal source is still the PPU's A10/11 address pin, buffering the signal in a gate vs a copper trace doesn't make it emulation.
I agree 100%! What matters is where the signals go. Mapper controlled vertical mirroring isn't one bit different from solder pads vertical mirroring... it's the same from the point of view of the software, and it's the same from the point of view of the console. Calling something like this "emulation" is like saying that bankswitchable PRG-ROM isn't real PRG-ROM just because the mapper can change it dynamically... It makes zero sense.
Well, I just DON'T feel like agreeing with any of this so stop trying. Just saiyng it's such a mess, if you start to get picky with terminology and so on. I didn't mean it was "emulation", but it's more like mapper-controlled mirroring is something else entierely - a chip controls the mirroring and whathever is supported depends on the chip. It is different from hardwired mirroring. And in case a mapper controlled mirroring is used, hardwired mirroring bit is unused by iNES header. That's what I meant.
It seems you're too hung up on HOW the various mirroring layouts are achieved rather than the mirroring layouts themselves. I guess it's understandable considering many of us aren't native english speakers and will easily associate certain words/expressions to the context where we first saw them in. Your brain probably hardwired "mirroring" and "header" together, making it harder for you to see the mirroring for what it really is: a memory layout.
But wording it like you did in this post would be extremely confusing for beginners (or anyone else, really), so if that was the idea behind your wiki edits, I can see why they were rejected.
One problem I see with the wiki is that it gets too freaking technical way too fast. It seems that in an attempt to make the topics clear and leaving no stone unturned, it goes into extreme detail about everything, including electronic signals and stuff that most programmers don't care about. The end result is that beginners don't understand shit, and even experienced coders have trouble locating simple pieces of information in the middle of unnecessarily large articles (I know I have trouble looking up stuff I already know on the wiki, when I need to get confirmation on something), so the format fails to cater to many people in the whole spectrum of NES coders.
Bregalad wrote:
Well, I just DON'T feel like agreeing with any of this so stop trying.
I don't feel the need to try and convince you to change your view. I'm just trying explain why I think your statements may have been confusing to Pokun.
tokumaru wrote:
Your brain probably hardwired "mirroring" and "header" together, making it harder for you to see the mirroring for what it really is: a memory layout.
From
iNES#Flags 6: "Some mappers, such as MMC1, MMC3, and AxROM, can control nametable mirroring.
They ignore bit 0." (my emphasis) How could this wording be improved?
tokumaru wrote:
One problem I see with the wiki is that it gets too freaking technical way too fast. It seems that in an attempt to make the topics clear and leaving no stone unturned, it goes into extreme detail about everything, including electronic signals and stuff that most programmers don't care about. The end result is that beginners don't understand shit, and even experienced coders have trouble locating simple pieces of information in the middle of unnecessarily large articles (I know I have trouble looking up stuff I already know on the wiki, when I need to get confirmation on something), so the format fails to cater to many people in the whole spectrum of NES coders.
As someone often struggling with data sheets and other technical papers I couldn't agree more with you. Even some basic things that are even easy to find in official development documents, like possible sprite or scroll coordinate values may be hard to find in the wiki, often hidden in a sea of technical text.
Although it maybe can't always be helped, I feel that some wiki pages are really bad at separating NES developer and emulator developer explanations. For example the APU pages are among those that gets really technical and are probably not much help for a normal musician. The mirroring page is another which, I guess, is why Bregalad doesn't like it. Although it has been improved a lot with pictures and such since I tried to wrap my head around mirroring for the first time a few years ago.
Personally I'm keeping notes of every hardware register and how to use them, in layman language (plus some useful technical notes). This gives me a clear overview of the hardware and it's easy to use for reference.
Pokun wrote:
I feel that some wiki pages are really bad at separating NES developer and emulator developer explanations. For example the APU pages are among those that gets really technical and are probably not much help for a normal musician.
That's why blargg put together a
simplified, NES programmer-oriented model of the APU. It starts by presenting init code that disables "tricky" features, such as the length counter, envelope unit, and sweep unit, and then passing off writes not conforming to the model as "undefined behavior" within the context of the model.
What other parts of the NES would be amenable to this sort of simplification?
I'd say that's more of a tutorial than a reference, but I guess it does fill a gap.
I can't think of any particular wiki page that needs something like that. Maybe the page about scrolling is in need of a bit lighter explanations. But the problem is more about the structure of the articles I think. It's a good thing that the wiki pages are attempting to explain everything, but sometimes things could be structured in another way that explains the most important things, that people are likely to be searching for, first and put more technical details after that, or in a separate section. I think that could help both beginners and anyone else just looking for reference information.
I don't have a clear picture of how to structure things though, I can only give constructive criticism of how things are now.
I think separating info for NES developers and emulator developers (like already done in several wiki pages) where applicable is the way to go though.
BTW I think the "Programming [mapper]" articles are quite good at clearing things up for a NES developer. That's something more mappers could use, including the FDS.
Pokun wrote:
I can't think of any particular wiki page that needs something like that. Maybe the page about scrolling is in need of a bit lighter explanations.
That's what
"The common case" at the top of "PPU scrolling" was intended for. Put the stuff needed for games that don't split at the top, and the rest is a revision of Loopy's "skinny" doc for games that split and for emulators.
Part of what I liked in
Bregalad's proposal seemed to be the creation of a third article besides
Mirroring and
PPU scrolling, which I suggested might be called
Scrolling techniques.
The idea here was to have a place to outline more specific applications synthesizing Mirroring and manipulating the PPU scrolling registers into particular scrolling techniques. Sort of like that
chart at the bottom of Mirroring, but explaining in more detail. The practical application of these two things rather than just the technical explanation of what they are.
Sounds like a good idea to me. Horizontal scrolling with the Sprite 0 Hit technique is mentioned in many places, and there's even a Nerdy Nights tutorial for it, but detailed information of the other common techniques is more scarce.
tepples wrote:
Pokun wrote:
I can't think of any particular wiki page that needs something like that. Maybe the page about scrolling is in need of a bit lighter explanations.
That's what
"The common case" at the top of "PPU scrolling" was intended for. Put the stuff needed for games that don't split at the top, and the rest is a revision of Loopy's "skinny" doc for games that split and for emulators.
I see, I guess those things requires deeper understanding of how scrolling works, and in that case you can't avoid getting technical.