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.)