It is currently Mon Jun 17, 2019 3:40 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 58 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Thu Jan 10, 2019 6:05 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
The reason I suggest that is that I think for the canonical 4-screen case it creates a redundant and error prone situation to try and include it as CHR-RAM.


For most mappers you should be able to substitute CHR-RAM for CHR-ROM and have exactly the same behaviour, and exactly the same size for the CHR-RAM version as CHR-ROM. Swapping ROM for RAM should not affect anything else, it should be unrelated to other factors as much as possible.

Similarly, canonical 4-screen should also be as orthogonal as it can be. 4-screen should just mean there is automatically 4k of dedicated RAM, and it shouldn't interfere with or interact with anything else. We shouldn't have think about whether the cart did it as 2k of RAM + CIRAM, or completely internal 4k, etc. any hiccups like that should only be non-canonical mapper-specific exceptions. It also shouldn't add on to other CHR-RAM that's only used for pattern tables. 8k + 2k? 8k + 4k? 16k? The standard 4-screen meaning should not require determining interactions like this. It should just be able to "drop in" on most mappers without having to parse the other fields to figure it out.


With mapper 77, you could call it 6k CHR-RAM + canonical 4-screen 1..0. You could also call it 8k CHR-RAM + 1..0, but I don't think that's canonical anymore (at least not by the way I suggest defining it); in this case it's a special variation of 4-screen where you're specifically including 2k it as part of the CHR-RAM. 0..0 "mapper defined" + 8k CHR-RAM also seems valid to me, which is just as much a special case. ...but there is only one possible thing to emulate here, all of the PPU-RAM is implied directly by the mapper, so arbitrarily even putting a 0 in the CHR-RAM field seems valid to me. (I don't really have a preference between these 3 possibilities, but I think it's an inherently ambiguous case that can't really be resolved by anything less than a special callout. Otherwise I think interpretations are going to differ here for any way we might attempt to define around making it a special case.)


In 356/512 it sounds like it's a completely separate and dedicated RAM just for nametables in the specific mode. That seems like a part of the mapper itself, not a "CHR-RAM" chip that needs to be specified as +4K on the CHR-RAM value. MMC5 ExRAM seems like the same situation to me, I wouldn't expect to put +1k into the CHR-RAM field for that. That's sort of what bugs me about trying to put it in the CHR-RAM field. It puts complicated interactions into the parsing of that field.


Though a way to demonstrate what I'm suggesting is that you should be able to take a UNROM with 8k CHR-RAM, and then set 1..0 for canonical 4-screen, and just get that without having to now specify 10k or 12k or 16k or 32k CHR-RAM. If you want to implement it any other way than some dedicated separate nametable RAM, it should be a new mapper or special case definition (like UNROM512).

Even though putting a flat 32k SRAM across the PPU address space would be the most straightforward way to build a simple CHR-RAM + 4-screen mapper, this should not be included in the canonical 4-screen case, it should be a special case. The canonical has to be more restricted than that, especially w.r.t. the $3000-3FFF mirrored area, because otherwise it's incompatible with the original 4-screen mappers that did it with half CIRAM. In the example I just gave, would 10k and 16k/32k have functionally different meanings (half CIRAM, mirrored twice, vs. no CIRAM and no mirror), and 12k would be functionally the same as 10k but somehow explicitly saying not to use CIRAM...? These possibilities feel really weird to me, and I think there's a lot of unpleasant room for interpretation if you go that route.


At least, that's what I would suggest as the standard/canonical definition of 1..0. The examples I'm giving about taking an existing mapper and changing ROM to RAM, or fixed mirroring to 4-screen, etc. obviously the games for this don't exist at this point, but the question that is in my mind is if I'm an emulator parsing a header, or a homebrew author trying to choose a mapper, can I deduce what's will/should happen if I take old mapper X and write "4-screen" in its header? Can I know what happens if I write 0 CHR-ROM and 256 CHR-RAM? The less interaction between fields, the less room for interpretation there is.

My approach may be unwarranted though. You could also decide that any mapper that has not already established a 4-screen variant is not allowed to use that bit... though in that case we should have to say that each of the ones that can use it is special. (Though, that's still a pretty small an practical list?) I had for a long time felt comfortable in thinking of the 4-screen bit as something that could at least in theory be easily applied to a great many mappers, but I'm not sure if others feel that is even a necessary goal. (In practice... support for it is very restricted in many emulators, I think.)


Last edited by rainwarrior on Thu Jan 10, 2019 6:42 pm, edited 3 times in total.

Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 6:11 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
Though, I might suggest that for the sake of assisting interpretation, since the number of different categories of 4-screen mapping is pretty small, it might be prudent just to make a list of all of them as a supplement to whatever specification you decide on. Based on what I've seen I think the definition for this is going to be difficult to parse/interpret, no matter which way it ends up, and some more direct clarification could go a long way toward stabilizing it.

Not really a list of all games, just a list of mappers which currently have 4-screen games + what to put in their mirroring and CHR-RAM fields. (Maybe a table at the bottom with an internal link from the relevant fields.)


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 6:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
In a wiki edit, Lidnariq wrote "Mapper 77 doesn't map anything at all to PPU addresses $3000-$3FFF." What does it do with this address? Open bus?

Actually, I had assumed that all the old 4-screen mappers had $3000-3FFF as a mirror for $2000-2FFF, but maybe I was wrong in that assumption. Are they all the same or different? It's possible that $3000-3FFF has no canonical 4-screen behavior at all and must always be mapper specified? (This is something that the wiki seems to have very little to say about.)

...though of course in practice this region is not likely to matter at all for basic game compatibility, but the stated goal here is to be completely specific about the implementation.


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 7:03 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
rainwarrior wrote:
In a wiki edit, Lidnariq wrote "Mapper 77 doesn't map anything at all to PPU addresses $3000-$3FFF." What does it do with this address? Open bus?
Correct.

Quote:
It's possible that $3000-3FFF has no canonical 4-screen behavior at all and must always be mapper specified?
I'm not confident it's consistent for any given mapper. The games that add a 2 KiB RAM and decoding logic most likely ignore PPU A12 and thus mirror into $3000-$3FFF ... but they also might leave it open bus. Certainly 800004 and DRROM use a 74'00 to generate a one-of-two demultiplexer, and there aren't enough inputs for PPU A12 to enter into the equation.
The games that use an 8 KiB RAM may leave A12 unconnected, making $3000 a mirror of $2000 ... but they may also have naively connected PPU A12 to RAM A12, making it an obtuse but technically available extra 3.75KiB of RAM. TR1ROM uses an 8KiB RAM with no extra decoding logic, but the only image in NesCartDB is both bad quality and only of the front, so I can't trivially find out which.


Top
 Profile  
 
PostPosted: Thu Jan 10, 2019 11:41 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
rainwarrior wrote:
MMC5 ExRAM seems like the same situation to me, I wouldn't expect to put +1k into the CHR-RAM field for that.
The problem is that because we put MMC6's internal WRAM into the PRG-(NV)RAM field, we in fact would put MMC5's ExRAM into the CHR-RAM field for consistency, unless it is put into the PRG-RAM field, where it seems to be more logical to put since as I understand the wiki it is still halfway-accessible there even in modes 0 and 1, and the same RAM should not be included in both fields since it only exists once. But yes, EXRAM is another can of worms that I have not thought about before. :?
rainwarrior wrote:
The standard 4-screen meaning should not require determining interactions like this. It should just be able to "drop in" on most mappers without having to parse the other fields to figure it out.
I am not sure what the advantages of such orthogonality would be. The memory area mapped to PPU $2000-2FFF has to be allocated by the emulator based on some kind of information. I would like to minimize the amount of differentiation one has to do, and always mapping to CHR-RAM included in its size field would accomplish that. I want to minimize the number of situations where, after having all these size fields in the header, more memory keeps just popping up because of this or that header bit. Right now, that occurs only in the case of Namco 163 chip RAM and the Datach main unit's EEPROM. The first is acceptable since it is not directly mapped into CPU or PPU address space, sort-of "out of sight", and the second one because it is not part of the game cartridge being described by the header.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 12:30 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
Why do you think the "somewhere" is messy? I think it's the only non-ambiguous way it can be applied generically and orthogonally. You don't even have to look at the CHR-RAM field to apply it, you know exactly where to put it, and can use the same implementation across all mappers that support it. Can even reasonably be statically allocated by the emulator.

Edit: Sorry, I seem to have missed an edit to the above when replying. There was some snippet of Nintendulator code being used as an example of putting the nametable RAM "somewhere" vs in CHR-RAM that I was responding directly to.

Otherwise, you have to make arbitrary decisions about where in the extra CHR-RAM it goes, how to mirror it, what portions of the CHR-RAM are bankable or not, etc. This seems like a big parsing problem to me.

Especially there is a combination problem with the separate goals of being able to substitute CHR-RAM for CHR-ROM interchangeably, and being able to add 4-screen independently. Here's a couple of hypothetical headers for some mapper that has CHR banking, and standard hardwired nametables:

1. 32k CHR-ROM, 0k CHR-RAM, 0..0 hardwired
2. 32k CHR-ROM, 0k CHR-RAM, 1..0 4-screen
3. 32k CHR-ROM, 2k CHR-RAM, 1..0 4-screen
4. 32k CHR-ROM, 4k CHR-RAM, 1..0 4-screen
5. 0k CHR-ROM, 32k CHR-RAM, 0..0 hardwired
6. 0k CHR-ROM, 32k CHR-RAM, 1..0 4-screen
7. 0k CHR-ROM, 34k CHR-RAM, 1..0 4-screen (Edit)
8. 0k CHR-ROM, 36k CHR-RAM, 1..0 4-screen (Edit: forgot this is not a usable CHR-RAM field value, but cases 7-8 here could be padded to 64k for the hypothetical I'm arguing.)

So 1 is some standard hardwired mirroring, no ambiguity here. 5 is the same board but with RAM instead of ROM, which should be completely unambiguous, no problem there.

Now what's the difference between 2, 3 and 4? Does it matter if the 4-screen RAM is supposed to be half CIRAM (3)? Is the added CHR-RAM supposed to go in the lower or upper nametables, or the two sides? If the header says 4k (4). With 0 in the CHR-RAM field (2), I think it's explicitly clear that the emulator has to provide the 4k itself, and no further decision needs to be made.

So 5 has a clear definition for replacing ROM with RAM, but what happens in 6 or 7? If canonical 4-screen is separate, there's no ambiguity in 6, and the bankable CHR-RAM continues behaving exactly as in 5. However, if it's not, then we're now insisting that that nametable RAM resides somewhere in that 32k and shares utility with the existing CHR banking schemes... that immediately becomes a series of mapper specific decisions about how this is going to behave. Should the nametables start at 0000 in that CHR-RAM? At 2000? At 6000? It also creates problems for someone who wants to convert something already using CHR-ROM to CHR-RAM, we can't just copy the previous data into RAM, we now have to make room for this extra 4k (or 8k) that gets eaten up by it...?

So okay, instead we want to explicitly make "room" for it in the CHR-RAM field, to give it its own orthogonal space... thus 7 or 8. These look like a nightmare to me. Now we have to recognize that 32k of this CHR-RAM goes into the mapper's usual CHR banking, and there's an extra 2 or 4k that gets combined with CIRAM for a separate nametable function?

I think any case where we have to mix nametable RAM into the rest of CHR-RAM has to be a mapper specific thing. For UNROM512 or GTROM it looks good to have 32k CHR-RAM in the CHR-RAM field. For mappers 356/512, I don't think it'd be good to have 4k CHR-RAM sitting next to 512k CHR-ROM (or whatever it is these things have). We should have either CHR-ROM or CHR-RAM but not both, except in special cases, so that it remains interchangeable.

Mapper 77 I'm ambivalent about. It's a special mapper that definitively has both CHR-ROM and CHR-RAM. Fundamentally, though, I think the "CHR-RAM" field should really be about stuff that's used for CHR tiles ($0000-1FFF), and if it gets used in nametables or other places that's some mapper specific override, not a generically applicable function.

NewRisingSun wrote:
(MMC6 WRAM)

Okay, well I don't think this is a fair thing to compare with, and I think trying to make a definition that fits every single case, not only 4-screen RAM and CHR-RAM uses but also PRG-RAM uses across all possible mappers... this is an impossible set of constraints to design a definition for. This just doesn't work. MMC6 is already a solved problem, and perfectly fine sitting in the PRG-RAM field where it is. I think you can do no better than saying "use 2k in the PRG-RAM field for MMC6" as a special case, and that's the end of it. Anything else you try to pile on this as a generic definition will make it more complicated.

The biggest difference between these two fields is that PRG-RAM is not a substitution for PRG-ROM in the way that CHR-RAM can be for CHR-ROM. Though... substituting them doesn't actually come up in games that much, this is mainly a homebrew concern, I guess, and largely hypothetical. Old emulators aren't going to grow support for weird CHR-RAM substitutions and 4-screen mappings, so maybe it's OK if this kind of usage becomes new mappers anyway... mostly I'm trying to outline how I would assume to use these fields, and the kind of usage that would be intuitive to me, but I can't make an argument for what's really best based on what I think is intuitive, only consensus will help with that.


Last edited by rainwarrior on Fri Jan 11, 2019 1:24 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 12:59 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
Yes, I removed the emulator code because I reconsidered that a format specification should not be defined by the whims of particular emulators.

Mapper 77 actually turns out to be irrelevant for the CHR-RAM size question because we cannot specify 6 KiB of CHR-RAM anyway. 8 KiB CHR-RAM including two nametable pages or 6 KiB CHR-RAM excluding two nametable pages padded to 8 KiB because 6 KiB cannot be specified amounts to the same header.

Having thought about EXRAM, I would say include it neither in PRG-RAM size nor CHR-RAM size because it is not clearly either?

And for 4-Screen, then let's go back to the previous standard: outside of CHR-RAM size if it cannot be mapped into the pattern table address range, and inside if it can. Makes no difference for Mapper 77 as mentioned. That means that Vs. games do not get a CHR-RAM size specified for the 4 nametables either.

What about Vs. System's 2 KiB of shared WRAM --- specified as PRG-RAM or not, because it's part of the different console type and not the game (quite an arbitrary distinction in the Vs. case)?


Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 1:14 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
NewRisingSun wrote:
Mapper 77 actually turns out to be irrelevant for the CHR-RAM size question because we cannot specify 6 KiB of CHR-RAM anyway. 8 KiB CHR-RAM including two nametable pages or 6 KiB CHR-RAM excluding two nametable pages padded to 8 KiB because 6 KiB cannot be specified amounts to the same header.

Ah yeah, had forgot that 6k isn't an option. Anyway, either 1..0 or 0..0, or 0k or 8k all seem "fine" to me for this mapper, if you want 1..0 + 8k, I have no preference, but I think it needs a 1 line special case definition to clarify what to do for it.

NewRisingSun wrote:
Having thought about EXRAM, I would say include it neither in PRG-RAM nor CHR-RAM because it is not clearly either?

Agree.

NewRisingSun wrote:
What about Vs. System's 2 KiB of shared WRAM --- specified as PRG-RAM or not, because it's part of the different console type and not the game (quite an arbitrary distinction in the Vs. case)?

Since it's in the normal WRAM place, I think it's fine specified as PRG-RAM. Very similar to MMC6. If it's not specified, I think the emulator would have to put RAM there anyway. So... another arbitrary case worth a clarifying line, IMO.

NewRisingSun wrote:
And for 4-Screen, then let's go back to the previous standard: outside of CHR-RAM size if it cannot be mapped into the pattern table address range, and inside if it can. Makes no difference for Mapper 77 as mentioned. That means that Vs. games do not get a CHR-RAM size specified for the 4 nametables either.

I would agree that it's best not to put 4k in the CHR-RAM field for Vs. System's 4-screen, for the reason of orthogonality.

I am not sure how I feel about the more generic guideline given here... whether or not it maps into $0000-1FFF might be sufficient (what was "previous" standard?) but I guess it's probably good enough to describe existing cases.


Top
 Profile  
 
PostPosted: Fri Jan 11, 2019 12:58 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
NewRisingSun wrote:
What about Vs. System's 2 KiB of shared WRAM --- specified as PRG-RAM or not, because it's part of the different console type and not the game (quite an arbitrary distinction in the Vs. case)?
As far as I can tell, those 2KiB are required for Vs. DualSystem games ... and Vs. SMB ... and nothing else. But there is something convenient about having it marked whether a game uses it.

At the same time, because the 2 KiB are not necessarily available, I don't think it's appropriate to mark all Vs. UniSystem games have 2 KiB available...


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 11:44 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
So trying to address existing ambiguities in how the mirroring bits have been used historically, here's three guidelines to remove the ambiguity that exists in current usage. Sort of a concise way to say to leave the bit as 0 when there's two ways about it:
  • If mirroring is mapper controlled, use 0..0 and not 0..1.
  • If the mapper has fixed 4-screen, use 1..0 and not 1..1.
  • Mappers 30 and 218 have special meaning.

As for which of the other mappers should use 1..0, there seem to be use cases for the following:
  • MMC3 (4-screen option) Rad Racer 2
  • 206 (4-screen option) Gauntlet
  • 77 Napoleon Senki
  • Vs. System
  • GTROM Edit: Forgot this has two banks for nametables. Could also be "0..0 mapper controlled".

We were attempting to define what standard meaning of the 4-screen designation should be, but after considering the behaviours at $3000-3F00 (which could really use some documentation on the wiki), I don't think it's a good idea to have the iNES header spec define the exact behaviour, only a more broad category:
  • 4k of nametable RAM fixed at $2000-2FFF, not able to be replaced or rearranged within that space.

I think that addresses the 5 cases above where it is already in use. Have I missed any?

As for how it applies theoretically to all the fixed-mirroring mappers, I think that would ultimately be subject to the same problem. The most practical thing to do for e.g. UNROM might be a flat RAM, combining but not overlapping with its traditional CHR-RAM. On a board with CHR-ROM, maybe decoding a more narrow range would be more practical. I don't think there's enough to specify which should be used right now. Though we've talked about it many times in the past, nobody appears to be using those mappers for 4-screen homebrew, AFAIK?

So ultimately... I don't think you can make a hard spec that will cover that theoretical future use overlapping existing mappers. I think in the 5 cases I listed above, they are all compatible with the broad category I gave, but the more specific behaviour is pretty divergent among them. The "accurate" behaviour of 4-screen is therefore, unfortunately, always mapper defined, IMO.

Other than this, mappers 356 and 512 were mentioned. I think these are both 0..0 mapper controlled?


The other question was what to put in the CHR-RAM field:
  • MMC3 - 0k
  • 206 - 0k
  • 77 - 8k
  • Vs. System - 0k
  • GTROM - 32k
  • UNROM 512 - 32k

This is consistent with what I suggested earlier, that we should theoretically be able to swap CHR-ROM with CHR-RAM if its practical, which it should be for MMC3/206 and Vs. System? Mapper 77 couldn't ever switch since it contains both. GTROM can't do 4-screen without its CHR-RAM, and neither can UNROM 512, though the latter could do CHR-ROM in its other 3 configurations.

Otherwise I do not think we should try to define how it might apply to any of the other mappers that could but don't currently have 4-screen variation. Wait for the use cases first, and this is much less of a problem to sort out.


Last edited by rainwarrior on Mon Jan 14, 2019 2:12 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 12:12 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8379
Location: Seattle
rainwarrior wrote:
4k of nametable RAM at $2000-2FFF, not able to be replaced or rearranged within that space.
I'd be tempted to add "and cannot be reused for tiles" ... but
* 4-screen variant of UNROM512 can
* in GTROM its 4 screens can be replaced by a different 4 screens.

I don't think we need a bulletproof definition, though. (hope we don't need?)

Quote:
Mapper 77 couldn't ever switch since it contains both.
On the one hand, I can't see a way for my following musing to ever matter, but...

Napoleon Senki has twothree memories on the CHR side, for a total of 40 42 KiB of address space. While "only ROM on the cart" has the same problem that UNROM512/4 does, "only RAM on the cart" would actually be a usable configuration.

(On the other hand, one wouldn't bother with two physical chips. In practice one'd just use a single 32K RAM, similar to UNROM512, and then it'd behave differently enough that it'd need its own mapper number)


Last edited by lidnariq on Mon Jan 14, 2019 5:30 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 12:19 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
Oh! I forgot that GTROM had two pages. Might be an argument that it should be 0..0 mapper controlled then.

Edit: on the other hand, I have subsequently had a conversation with a few homebrewers that are working on GTROM games. Universally their intuition was to put 1..0 there. Maybe that's a case for keeping the definition a little wider, so that it's closer to what most would expect.

As far as I know, there has never been a public ROM of a GTROM game so far. All the releases I know of are from the cartridge-only crowd. Emulators have to ignore the mirroring bits by this mapper definition anyway.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 6:35 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
The current wording on the NES 2.0 wiki page implies that the 4-screen bit is invalid when the mapper does not support 4-screen mirroring, in particular the sentence "Currently, only the four-screen variants of mappers 4 and 206 as well as 77 and the Nintendo Vs. System meet that definition". A discussion on the iNES page however has shown that some people expect the 4-screen bit to override any mapper-controlled mirroring. My opinion is that while iNES is not clear on that issue, NES 2.0 should be clear. So: Should the 4-screen bit on, say, CNROM be usable to create a hitherto unheard-of CNROM-4-Screen board?


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 8:43 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7717
Location: Chexbres, VD, Switzerland
NewRisingSun wrote:
My opinion is that while iNES is not clear on that issue, NES 2.0 should be clear. So: Should the 4-screen bit on, say, CNROM be usable to create a hitherto unheard-of CNROM-4-Screen board?

iNES is very clear - when this bit is set you get 4-screen mirroring. Only on mappers where this conflicts with something would that be unclear. And we agree that NES 2.0 should be clear, but if I remember well it should also be retro-compatible with iNES whenever this is possible.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 9:59 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
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 word "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.

(Edit: Spelling)


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

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

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