It is currently Tue Sep 19, 2017 12:03 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Tue Aug 22, 2017 4:25 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 748
Location: Sweden
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).


Top
 Profile  
 
PostPosted: Tue Aug 22, 2017 4:33 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 852
Location: Gothenburg, Sweden
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.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Tue Aug 22, 2017 5:32 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 748
Location: Sweden
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"?


Top
 Profile  
 
PostPosted: Tue Aug 22, 2017 5:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18984
Location: NE Indiana, USA (NTSC)
On most ASIC mappers (MMC*, FME-7), the mirroring bit is indeed a don't care.


Top
 Profile  
 
PostPosted: Wed Aug 23, 2017 4:08 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 748
Location: Sweden
I see, I think the wiki wasn't entirely clear on this. Also I still don't get what Bregalad meant.


Top
 Profile  
 
PostPosted: Wed Aug 23, 2017 4:55 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1874
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Wed Aug 23, 2017 6:24 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10008
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Wed Aug 23, 2017 11:37 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7202
Location: Chexbres, VD, Switzerland
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.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 5:20 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10008
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 6:07 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1874
Location: WhereverIparkIt, USA
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.

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 7:58 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18984
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 8:15 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 748
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Thu Aug 24, 2017 8:29 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18984
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 11:13 am 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 748
Location: Sweden
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.


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 1:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18984
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group