nesdev.com

Operation Wolf and Bayou Billy both have Zapper and Zapper-Free options, I think.

Is there much need to try and account for multiple possible input configurations? I feel like this field is more about specifying a useful input set where the standard option doesn't work. If it's a multiple choice thing, probably specifying the most standard (subjective, I know) option is fine?

No, because when you connect the Zapper, Bayou Billy and Operation Wolf still allow you to use the controller, so an emulator can plug in the Zapper just in case without restricting the user's choices. I have rephrased Note 1 in the Input Device proposal accordingly. The only difficulty that will remain is when several options conflict by using the same controller data bus fields and so cannot be connected simultaneously.

I'm not entirely certain the logic of why something that is inherently in the 2a03G and exists would not be added into NES 2.0 specs; as opposed to Famiclones that are based on the hardware but may have different PPUs or palettes. Vs. and Dual units are available as well. It's apparent that the NES 2.0 format's purpose is to include as many multicarts, Famiclones, arcade hardware, peripherals, and features of the NES as possible; making it as future-proof as it can be; including additions of homebrew mappers and peripherals.

If someone really wanted to, there shouldn't be any way to stop them from creating a visualizer demo for the triangle register, etc. and something to make it easier for the emulator to know that TEST mode needs to be enabled.

But no such Visualizer exists yet. You are asking for an entry for a hypothetical ROM that may or may not ever be created. Let somebody make such a Visualizer, and then we'll see.

By the way, I am very much in favour of the input enumeration field. I actually suggested the same thing 4 years ago but nobody in that thread seemed to like the idea. I think it would be very nice if emulators had a way of knowing which devices to use.

There as another relevant thread about a year ago wondering about how to include extra data besides PRG/CHR.

There was another suggestion I had that the new byte 9 as "upper bits of ROM size" was ill conceived, as there are already ROMs in the wild bigger than it fits (e.g. 1 bit shy of "A Winner is You" 64MB PRG). You could use the same 4 bits as an power of 2 exponent instead of as an extended binary number and we'd always have big enough size. However, I don't know to what extent these bits are already in use, so I am not sure how appropriate it would be to consider revising it at this point. (Edit: found the previous discussion which was also asking about the utility of values like 0 or 255 in the iNES1 PRG size field.)

3gengames' objection is strongly-worded but unpersuasive. In any case, there are still some open questions in the input device field's thread, in particular whether it should include the expansion port storage devices or not.

The largest ROM image in the wild is 128 MiB, but there is no reason that it will stay that way. How about if byte 9 is FF, then the PRG-ROM size is 64 SHL byte 4 and CHR-ROM size is 64 SHL byte 5. (Byte 9 being FF would otherwise denote 62,914,560 to 67,092,480 bytes of PRG-ROM plus 31,457,280 to 33,546,240 bytes of CHR-ROM, both slightly less than 64 and 32 MiB, a value so unlikely that it can safely be used for a special meaning.) A maximum size of 64 SHL 255 should hold a while. (And it will finally at last allow for a non-overdumped Galaxian! (ducks away))

I kinda like that use instead of 2^15. Heaven help us when we finally reach the 64GB homebrew though.

Though we could even bias the exponent something like +4 or +6 and trade away some not-very-necessary non-power-of-two precision for even bigger sizes. +5 would get us to 1TB.

Oh, as far as the "test pin" thing, I think the thought of it being a potential input enumeration is kind of convenient. You might think of lifting and rewiring that pin as a similar "input device" situation as expansion ports. The convenient part though is since the enumeration is a living and open spec, easy to add to as cases come up, allocating that enumeration can certainly wait for a real ROM to use it with. Kinda meets both needs at once (i.e. "I want the spec to be able to support this" and also "I don't want to waste spec on something that has no use case".)

I think there's actually a fairly firm limit at 256 MiB—that's the size of the largest NOR flash available. (and that's both BGA only and also more expensive than two 128 MiB ROMs)

I'm a little worried about not supporting multiple ROMs of dissimilar size without explicitly encoding mirroring in the dump.

(I'm also pretty certain that there are no market forces suggesting we will ever see silicon dice holding even more bytes)

Actually the "64 shift" though made me think a little more minimally: if a nonzero value in the oversize ROM nybble just specified that the original byte 4/5 is now an exponent, the range now easily extends from 1 byte to eternity. Could even use the 15 values to specify an odd multiplier to accomodate 14 different varieties of non-power-of-two sizes.

0 -> (original 16k * N)
1-15 -> 2^N * [1,3,5,7,9,11,13,15,17...]

Kind of turns the original byte into a "chip address size" and the oversize nybble into a "chip count".


(I'm just golfing here, though. I'm not personally very interested in gigantic ROMs. The existing size spec is plenty good enough for everything I selfishly care about.)

Actually... maybe you could even keep it compatible with the current spec. With things as they are, the oversized nybble $F is practically useless anyway, so you could treat that value as a new special value to mean the original byte is reinterpreted exponentially/floating-pointish.

For example, you could use 2 bits for multiplier, and 6 bits for exponent you'd have 2^[0-63] x [1,3,5,7]

...or 3 and 5 would still get you to 2GB... or you could bias the exponent by +10 and only have 1k granularity but go up to 2TB.

Really there's tons of expressive room just in the original byte this way. (Sorry for rambling on about something I don't actually think will ever be useful, ha ha. Just the more I thought about it, the more it seemed like bits were being wasted here.)

Per MAME and Nocash, we know of six (seven) total games that use the Vs. System's ability to communicate between the two CPUs:
* Balloon Fight ("balonfgt")
* Baseball ("vsbball", "vsbballj", "vsbballja", "vsbballjb")
* Ice Climber ("iceclmrd")
* Mahjong ("vsmahjng")
* Tennis ("vstennis", "vstennisa", "vstennisb")
* Wrecking Crew ("wrecking")
** (Raid on Bungeling Bay ("bnglngby"))

All of these run directly on the MDS mainboard without extra bankswitching hardware; they're all technically mapper 99. Of these, five are 32K PRG and 16K CHR on each side. Mahjong has 24K PRG and 8K CHR; Raid on Bungeling Bay has 8+32K PRG and 0+16K CHR.

Earlier in this thread, NewRisingSun suggested packing both CPU's PRG and both PPU's CHR into a single file.

This is not quite entirely unambiguous. I am uncomfortable with defining 16K CHR to mean two different things depending on the size of PRG. Additionally, this naive concatenation rule runs into problems between Raid on Bungeling Bay (0+16) and Vs. Mahjong (8+8). Since defining either of these as the "correct" definition only allows a single game to be emulated, and requires that the other be padded up to 32K CHR in the file, I'm inclined to say that both should require padding CHR, and the 64K PRG+16K CHR configuration shouldn't be allowed in a mapper 99 DualSystem image.

(Vs. Mahjong does not use the CHR bankswitching ability, but it is directly on the MDS mainboard and so is technically mapper 99, not mapper 0. Additionally, I'd like to keep this logic all confined to mapper 99, if practical, rather than defining an alternative behavior in another mapper to handle a single game.)

I'm also a little uncomfortable with having something that looks like an ordinary NES file but suddenly pops up two screens and requires four controllers, but whatever.

As a final worry, mapper 185 was explicitly defined because people didn't like baked-in padding in the corresponding NES images. (All of the games would run if dumped and emulated as 32K CHR CNROM). So defining padding into the encapsulation—at least for the instances where the padding isn't an artifact of the limited precision of the ROM size fields in the header—is directly contrary to the goals that lead to the definition of mapper 185.

Does anyone else have any thoughts on this matter?

You are not defining 16 KiB CHR to mean two different things depending on the size of PRG. You are defining 16 KiB CHR to mean two different things depending the console type field.

As for padding, I see it less like Mapper 185 and more like padding Galaxian from 8 KiB to 16 KiB PRG.

I have already implemented Vs. Dual support in Nintendulator-NRS, and added the ability to only view one of the screens. The four controllers are reused from the user's NES Four Score configuration. The only thing left to add is mirroring of the P3 and P4 controls when using a single screen only. This has to be game-specific --- Vs. Tennis must invert both horizontal and vertical controls, Vs. Wrecking Crew only the horizontal ones, and Vs. Balloon Fight none.

Since both Vs. Mahjong units' CHR-ROMs are identical, you only need to include 1x8 KiB, and let the emulator's mapper interface with its address wrapping capabilities do the rest. Both games run fine here without any hitch, so the problem you are describing seems to be entirely theoretical.

Ah, ok. 16KB CHR in Vs.Mode==0,9 is single PPU with 16 KiB CHR, 16 KiB CHR in Vs.Mode==7,8 is two PPUs with 8 KiB CHR each. 32 KiB CHR is only defined for Vs.Mode==7,8.

Well, the CHR padding concerns were due to not remembering the extra Vs. System modes.

I guess I'm still a little uneasy with adding 24 KiB of padding to Raid on Bungeling Bay, which does feel much more like mapper 185 than Galaxian to me.

Thanks for taking the time to post this!

I'm essentially done adding support for VS DualSystem, I just need to finalize the exact way Mesen expects the roms to be stored at this point. Personally I don't have any strong opinions on the subject - I just want to avoid creating 2 different implementations for the same thing.

Is everything in this thread still just a "proposal"? If everybody is ok with the proposals, I'm happy to implement them on my end.

Considering the game-specific header setting, the padding could be limited to just 8kb, I think? (and only because the iNES header enforces multiples of 16kb)

I was about to post updates to the proposals (this thread and the input device one) based on my experiences in implementing them in Nintendulator-NRS, sometime next week.

I would still like to solicit more input on how to deal with ROMs with more than 64 MiB of PRG-ROM.

Edit: We could use a completely unpadded Vs. Mahjong (banks A,C,E unit 1, banks A,C,E unit 2, yielding 48 KIB of PRG) and an Vs. Raid on Bungeling Bay padded only to 48 KiB. Here's what my mapper 99 bankswitching code would look like:Without such trimming, the "if (ROM->INES_PRGSize ==3)" block would be gone, yielding a much more streamlined implementation. Note: Bank 0x18 means CPU bank starting at $8000 of the second unit. OB4 means Open Bus. The trimming would also be kind of awkward for Vs. Mahjong because one of the 16 KiB banks would contain PRG data from both units.