It is currently Sat Jul 20, 2019 11:31 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
PostPosted: Tue Jan 15, 2019 11:16 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8486
Location: Seattle
I think I'm actually pretty comfortable with the notion of "you want a novel use of 4-screen layout? You must use a NES2.0 header"

As far as describing what the bit means in original iNES, I have to admit I was dismayed to read Rainwarrior's edit to the iNES page: “Mapper 70 had a 1-screen variant that was sometimes specified with bit 3 set. This was relocated to Mapper 152.” so it sounds like the mess with mapper 30 isn't even particularly novel.

(edit) I'd like to say that it "should" mean that the mapper always wants four screens of nametables, and this use is unambiguous in cases that never have mapper-controlled mirroring, but ...


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 1:10 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
lidnariq wrote:
I have to admit I was dismayed to read Rainwarrior's edit to the iNES page: “Mapper 70 had a 1-screen variant that was sometimes specified with bit 3 set. This was relocated to Mapper 152.”

Are you dismayed by the edit, or dismayed by the thing the edit describes? Do you think it shouldn't be acknowledged? My goal with the edit was to prepare someone for what they would actually find in existing iNES headers.

As for other goals defining these bits... I thought NewRisingSun was asking for clarification so that for things that exist where a bit was ignored, it should be clear how to set the ignored bit, so that we don't have 0..0 and 0..1 on equal footing for e.g. MMC1 games. That part of the goal seems fine for an iNES 2 clarification, which in a way takes up the unused variations as "reserved", though most probably they should never be used. I think that's a reasonable kind of "cleanup" additional thing to specify for iNES 2. (...and of course emulators can go on ignoring these bits just as they always have, so it shouldn't actually complicate implementation.)

As for specifying what every mapper is supposed to do when you set the 4-screen bit? No. This is impossible to specify. All actual practical ways of changing mirroring types like this involve build decisions that interact with the mapper, there is no generic way to fully specify this. A weakly compatible definition may be compatible with all mappers with hard-wired mirroring, but this deliberately has to ignore the details of what happens at $3000 and not pretend that this is an accurate specification of some sort. For mappers that already software control their mirroring? No, there is nothing we can insist about their non-existent potential 4-screen modes.

Any combination of mapper and mirroring that no released ROM is using is simply undefined and/or reserved. The specification should just be "don't use it". When new things exist, then the new things can find a new definition. Doing otherwise puts extra work on anyone reading/implementing the spec for no reason, and puts unnecessary complications and constraints on the future use of the format.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 1:17 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7720
Location: Chexbres, VD, Switzerland
NewRisingSun wrote:
Nothing is clear about iNES when it does not even have the ability to specify mapper-controlled mirroring, and it does not become clear just because you put the world "very" in boldface. I will take your comment down as a vote for "In addition to mappers 4, 77 and 206 that historically have existed in four-screen variants, the four-screen bit may also be specified with the same effect for any mapper without software-controlled mirroring." It is still unclear what to do with mappers that have software-controlled mirroring --- the wiki talk page says that it is supposedly "clear" that it also applies to MMC1 and MMC3, but not to mappers that have "complex VRAM features", whatever that means --- all very un-"clear" to me.

There also is an argument to be made that we should not allow the specification of headers that are impossible to replicate with original hardware. For example, it has been argued that no mapper 4 game with more than 512 KiB PRG-ROM should be allowed, because the MMC3 does not have PRG address lines beyond A18. Sure, you can specify a 2 MiB PRG-ROM and argue that this just means that an MMC3 clone with more address lines be assumed, and that all eight bits of bank registers 6 and 7 be considered. But it would be a different board than what is historically meant by mapper 4, and using such features precludes putting such ROM images on donor boards. Using 4-screen mode on mappers with no historical support for that seems to be a similar situation. Now, that of course would not mean that you must never create a CNROM-like PCB with four-screen mode, but you would just not be allowed to denote mapper number 3 for it under that regime.

Since it's not clear I'll make a nth attempt to clarify. The error you make is that you consider mirroring is linked with mappers. This is simply, in the original sense, not true. In the mindset of iNES, 4-screen mirroring is a cartridge-feature that can be coupled with any mapper, including no mapper at all (mapper 0). This is done by adding additional RAM for the nametables. Similarly, vertical or horizontal mirroring is selected with solder pads. This is independant of the mapper.

Now, there is mappers which overwrite the mirroring of their own. MMC1 and MMC3 are among those. Then bit 0 is ignored, but bit 3 still takes effect.

Then, there is "complex" mappers that does complex effects such as merging CHR-ROM/RAM with nametables or whathever. Those are considered special cases, and in those cases the mapper overrides the iNES mirroring bits.

It's weird that you said just because no game using mapper X has combined it with 4-screen VRAM, that it should be "forbidden". iNES was developped to allow combinations that didn't (yet) exist in hardware, for the better or the worst. I see no reasons those features would be forbidden.

EDIT : You are however right that many emulators authors could get lazy and not implement 4-screen VRAM features with mappers where it wasn't used and get away with it, thus a iNES 1.0 header can unfortunately not be sufficient for reliable emulation. But that's not because iNES is unclear, that's because emulator authors were lazy.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 1:37 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
Emulators are free to (and should be free to) implement whatever they want in response to undefined or reserved situations. Leaving behaviour undefined is helpful, it gives people room to breathe when implementing. This is an important part of a lot of technical specifications.

It also lets emulator authors do things like speculatively support 4-screen for fixed-mirroring mappers, which are perfectly harmless otherwise and potentially very useful for experimentation. All of that potential is harmed by telling people what they have to do with stuff that nobody is otherwise depending on being reliably specified.

There's no reason to demand that an emulator has to support the 4-screen bit for e.g. mapper 2, but it's very clear that Bregalad likes this potential, and according to the discussion on the iNES talk page it seems a lot of emulator authors liked it too. It's convenient to do if your code is structured in a certain way, but it's also convenient to ignore for now if it's not. This freedom is good to have!

What I do think could be helpful is to specify better where the boundary of "undefined" is. That's important so that people don't make assumptions about reliability of features. That's a careful boundary that should reflect how things really exist and are being used. The best guideline I can suggest is that if there is no ROM that needs it, it's not specified yet. That's the same rule of thumb that was being used to prevent spurious fantasy homebrew mappers from appearing on the WIki, or submappers with no testable or implementable specification. Don't pile currently untestable definitions onto the workload of people trying to learn/implement this stuff.

Bregalad wrote:
EDIT : You are however right that many emulators authors could get lazy and not implement 4-screen VRAM features with mappers where it wasn't used and get away with it, thus a iNES 1.0 header can unfortunately not be sufficient for reliable emulation. But that's not because iNES is unclear, that's because emulator authors were lazy.

No, this is not lazy. This is a perfectly reasonably thing not to emulate. There is nothing to emulate with it! iNES 2 doesn't change that in any respect.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 1:45 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7720
Location: Chexbres, VD, Switzerland
Quote:
It also lets emulator authors do things like speculatively support 4-screen for fixed-mirroring mappers, which are perfectly harmless otherwise and potentially very useful for experimentation. All of that potential is harmed by telling people what they have to do with stuff that nobody is otherwise depending on being reliably specified.

Emulators should support 4-screen mirroring, regardless of mappers. Those are orthogonal features. Except in some specific cases. Why is this so hard to understand ? Because your definition of 4-screen mirroring is not the same as mine (as previous talk on wiki) ?

Until the day before yesterday, I've NEVER heard that 4-screen mirroring could only be used with a restricted list of mappers. I might have not listened. This is similar to PRG-RAM and battery-backed PRG-RAM. iNES supports those regardless of mappers (including mapper #0 - no mapper) even if those cartrdiges configurations never existed.

rainwarrior wrote:
This freedom is good to have!

It might be good for emulator authors, but definitely not for game authors who aims to use 4-screen mirroring ! Half of emulators not playing their game just because emulators authors were lazy to implement iNES correctly, as no games used a combination of two features they support !

Quote:
Don't pile currently untestable definitions onto the workload of people trying to learn/implement this stuff.

At least we aree here !


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 2:00 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
Bregalad wrote:
Since it's not clear I'll make a nth attempt to clarify.
Oh, get off your high horse. This is the very first time that you have attempted to clarify anything. Before, you simply asserted that everything was clear and written the word "very" in boldface.
Bregalad wrote:
The error you make is that you consider mirroring is linked with mappers. In the mindset of iNES, 4-screen mirroring is a cartridge-feature that can be coupled with any mapper, including no mapper at all (mapper 0).
I am well aware of that line of thinking back in the iNES days. But today, we have a good understanding of board hardware and its limitations. NES 2.0 is based on that better understanding. Yes, NES 2.0 should be backwards-compatible to iNES to the extent described on the NES 2.0 wiki page. But that does not require still following iNES' way of thinking. In this context:
Bregalad wrote:
Half of emulators not playing their game just because emulators authors were lazy to implement iNES correctly,
I think that is actually the crux of the issue: modern emulators do not want to implement iNES correctly; they want to implement actual hardware correctly, and use iNES, NES 2.0 and UNIF merely as a means to describe actual hardware.
Bregalad wrote:
thus a iNES 1.0 header can unfortunately not be sufficient for reliable emulation. But that's not because iNES is unclear, that's because emulator authors were lazy.
That is all I was arguing for on the wiki. But you kept pestering me about "most emulators" which as it turns out nobody has even said.
rainwarrior wrote:
There's no reason to demand that an emulator has to support the 4-screen bit for e.g. mapper 2
But there is a demand (at least by me) to define what an emulator should do when it encounters a NES-2.0-headered ROM with that bit set, and the board specified by the mapper number did not originally exist in such a variant.
Bregalad wrote:
It might be good for emulator authors, but definitely not for game authors who aims to use 4-screen mirroring!
As mentioned before, there is disciplinary value in not allowing game authors to use features that were not available as such on actual hardware.

To sum it up: I really have no stake in either side. I am perfectly fine with adding to the NES 2.0 spec that "Header byte 6 bit 3 may not be specified together with mapper numbers describing board hardware that never existed in a four-screen variant; emulators should ignore the bit in those cases." I am however also fine with adding to the NES 2.0 spec that "Header byte 6 bit 3 may also be specified together with mapper numbers describing board hardware that never existed in a four-screen variant; emulators should override bit 0 or any mapper-controlled mirroring setting in that case." I really don't care which one it is, as long as it is defined one way or another.


Last edited by NewRisingSun on Tue Jan 15, 2019 2:04 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 2:02 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
Bregalad wrote:
It might be good for emulator authors, but definitely not for game authors who aims to use 4-screen mirroring ! Half of emulators not playing their game just because emulators authors were lazy to implement iNES correctly, as no games used a combination of two features they support !

Well, this is basically directly in the same category as "fantasy mapper" for me. Specifying how 100+ mappers should work with this bit just in case someone might make a homebrew for it in the future?

For actual homebrew releases that use 4-screen, there has been GTROM and UNROM 512. For the most reliable way to use 4-screen for homebrew, MMC3 is the clear choice. It's not even impractical to implement subsets of MMC3 on a homebrew board at this point. These are some good options that have already become real.

For the rest... what's the point in forcing it? If it remains unspecified and emulators are free to do what they've been doing, there's a lot of potential there to experiment. You can use some current emulators to test out your prospective project using 4-screen with whatever it is you thought was needed... and if you finally decide to release it, great! A bunch of emulators will already support it with not changes.

...and until that day, there's no reason to demand it via specification. Specifying it won't make that homebrew happen, it just leads people do extra work for nothing.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 2:25 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8486
Location: Seattle
rainwarrior wrote:
Are you dismayed by the edit, or dismayed by the thing the edit describes?
The latter. Dismayed that it had apparently happened.

NewRisingSun wrote:
to define what an emulator should do when it encounters a NES-2.0-headered ROM with that bit set, and the board specified by the mapper number did not originally exist in such a variant.
The only argument that occurs to me goes:

Given that the Vs. System always came with 4 screen layout, was used with a small but nontrivial handful of mappers, and never supported run-time mirroring control...
Therefore at least one of the two bits in the header (Four screen and "Vs system") should strictly override whatever mapper control is provided by that mapper and irrevocably force four-screen layout.

Yes, I know that's explicitly why you called out "the mapper number did not originally exist in such a variant". But I guess that's the root of it all, right? Prescriptive vs descriptive?

I like the uniformity of saying "the four-screen bit always means four-screen layout and the mapper IC can't opt out of it after the fact", but that has plenty of its own problems. Are we allowed to say that the behavior is explicitly undefined?


In practice, I guess, FCEUX's gross hack (it loads whatever ROM with four screens, subsequent mapper control writes irrevocably throw away the extra nametables) may actually be the compromise position.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 4:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
lidnariq wrote:
I like the uniformity of saying "the four-screen bit always means four-screen layout and the mapper IC can't opt out of it after the fact", but that has plenty of its own problems. Are we allowed to say that the behavior is explicitly undefined?

I think that's exactly the way to strengthen the specification. Explicitly undefined, which also means reserved.

It makes it clear that you should be putting 0 in this bit unless it's time to take in that reservation to put it to use. NewRisingSun wants it to be clear what should go into a header for any given thing that already exists. Saying to use 0..0 and not 0..1 for mapper-controlled mirroring addresses that. It also might help dispel misconceptions like "0..1 on MMC1 should power-on the mapper with that mirroring" that pop up from time to time.

Other than doing that, though, I don't know what iNES 2.0 is supposed to clarify over iNES 1 for this field. CHR-RAM size is definitely something that needs to be explained for iNES 2, but the mirroring bits from prior use are pretty consistent for the existing/defined iNES 1 cases, aside from a bunch of uses of bit 0 while it's ignored?

The existing use probably needs some improvement of documentation, which is why I started adding some info to the wiki's iNES page, but I don't see much role that iNES 2.0 has to play in this, other than taking back and reserving the undefined cases.

lidnariq wrote:
In practice, I guess, FCEUX's gross hack (it loads whatever ROM with four screens, subsequent mapper control writes irrevocably throw away the extra nametables) may actually be the compromise position.

I don't think anyone wants that. :P


Top
 Profile  
 
PostPosted: Wed Jan 16, 2019 12:25 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7720
Location: Chexbres, VD, Switzerland
NewRisingSun wrote:
As mentioned before, there is disciplinary value in not allowing game authors to use features that were not available as such on actual hardware.

Quote:
Well, this is basically directly in the same category as "fantasy mapper" for me. Specifying how 100+ mappers should work with this bit just in case someone might make a homebrew for it in the future?

This is where there is a disagreement among us. Sure, there was no games released on, say, mapper #2 and 4-screen mirroring simultaneously. However, we know how to create 4-screen mirroring (either by adding a 8k RAM on the board like Rad Racer 2, or by adding a 2k RAM and an extra chip to do the decoding, like Gauntlet). Both are functionally equivalent in terms of how the hardware responds and how it's emulated - only the actual hardware is different. In both of those cases, the VRAM is not connected to the mapper in any way. Thus this trick could easily have been made with any other mapper - it just happened by pure chance that both games using this feature happened to be on MMC3. But they could have easily built with any other mappers as well - again, this is completely orthogonal.

The same applies to PRG-RAM and battery bacup. It happened that some mappers had no games with PRG-RAM nor battery backup. But we know how it would be made, and they are supposed to be emulated fine, in the origianl iNES mindset. We agree this mindset is far from perfect, but nevertheless that's how it works whether we like it or not.

Quote:
In practice, I guess, FCEUX's gross hack (it loads whatever ROM with four screens, subsequent mapper control writes irrevocably throw away the extra nametables) may actually be the compromise position.

This is unacceptable for MMC1, as mirroring control bits are ont he same registers as other bits which should still be written to in case of 4-screen mirroring.

Quote:
You can use some current emulators to test out your prospective project using 4-screen with whatever it is you thought was needed... and if you finally decide to release it, great!

I currently have no plans for ever using 4-screen mirroring in any of my homebrews - but someone else could or why not in the future I could. I see no reason to be forced to use MMC3 "just because that's what the officially released games used".
When developing homebrew we require not any emulator but good accurate emulators such as Nintendultor or Nestopia - or with debugging features such as FCEUX.

EDIT : Now let's say that as a homebrewer I'd like to use 4-screen mirroring and MMC3, but with more than 128KB of PRG-ROM. Or more than 64KB of CHR-ROM. Or with CHR-RAM instead of CHR-ROM. Or with PRG-RAM and maybe why not battery backup. Neither of those were done by existing released games. Are they "forbidden" too, just because of that ? If yes, then at least the logic is coherent - i.e. "only emulates board which actually exists". If no, then it is completely incoherent.


Top
 Profile  
 
PostPosted: Wed Jan 16, 2019 12:53 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
Bregalad wrote:
I currently have no plans for ever using 4-screen mirroring in any of my homebrews - but someone else could or why not in the future I could. I see no reason to be forced to use MMC3 "just because that's what the officially released games used".

I'm not "forcing" someone to use MMC3, I was just suggesting it is just the mapper to use if the widest emulator compatibility is really your goal, as a homebrewer. That will remain true regardless of whatever we're talking about specifying.

Also, amusingly enough I did talk to one person earlier today who has been using BxROM + 4-screen, not really as their intended release hardware, but instead as a compatible surrogate for GTROM, which currently fewer emulators support than BxROM + 4-screen.


To be clear, I like that interpretation of bit 3 as applying to nearly everything, and I am perfectly in favour of emulators being able to implement that in this space, but that's part of why I think it should be explicitly undefined. This leaves it up to the emulator author as to what is practical/desired for it until we have a game that needs to be emulated with it, and at the same time doesn't burden anybody who isn't interested in potential maybe future games.

It also means that when hardware is actually created for it, we can see what arbitrary choices were made for that hardware, and specify exactly what it does, instead of overspecifying it right now ahead of the fact and probably getting it subtly wrong.


Top
 Profile  
 
PostPosted: Wed Jan 16, 2019 2:22 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
As I said before, I can live with any well-specified solution. I personally have no problem with saying "The H/V mirroring bit must be ignored, and should be clear, when there is mapper-controlled mirroring. The 4-screen-bit overrides any mapper-controlled mirroring and forces four independent non-bankable nametables at all times." The beauty of the last solution is that it would work nicely with the 4-screen versions of Mappers 4 and 206 as well as the Vs. System without having to specify any special rules for them. It still also works nicely with mapper 77 -- I do not think we can ever dispense with tautology for that one ---, and it follows nicely that it must not be set for mappers 356 and 512, for they must software-control H/V/4 mirroring types. That would indeed dispense with the "disciplinary value" criterion, but it's not something I am particularly invested in.

rainwarrior wrote:
It also might help dispel misconceptions like "0..1 on MMC1 should power-on the mapper with that mirroring" that pop up from time to time
I believe that actually came from the time when it was not known that the early Namco games used the N118 and not the MMC3, and was necessary in order to be able to run both as mapper 4. Thanks to the addition of Mapper 206, that annoying custom can be put to rest completely.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2019 2:08 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
I added a somewhat hedged sentence to the NES 2.0 wiki entry that attempts to resolve the issue by explaining what perfect iNES compatibility would entail but does not explicitly require such behavior.


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

All times are UTC - 7 hours


Who is online

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