NES 2.0 Additions Proposal

[NewRisingSun]

I oppose, because of one criterion: the header should be unambiguous; every game should have one header with values that are correct for that game, with any other being incorrect. That allows "good" ROMs to have one unambiguous CRC32 including the header. All the current and proposed fields meet that criterion, including the input device field as previously described. Denoting what is preferred on the other hand is inherently subjective and therefore ambiguous. You could have three times the same ROM image with three different headers because somebody prefers NTSC/PAL/Dendy, and have all three being correct according to the definition.

[rainwarrior]

I have not much to say about it as an iNES revision. I'll respond to the request to alter the 'regn' field though:


I don't think this is a useful addition. There is already "bitfield of supported systems" and "preferred system". What you're proposing seems to be partially approaching "ranked set of preferred systems" which I don't really see a good purpose for, and I think has ramifications that are an encumbrance on the implementation for how to correctly handle that ranking.

If you want Dendy or NTSC but prefer Dendy, then leave the PAL support bit clear, and vice versa. Why is that insufficient? You really have a use case where an NSF is going to support 3 regions differently and you need to prefer 2 of them over the 3rd?

The 'regn' field also has the option to omit preference, in which case all supported options are valid, and a user preference option might be supplied. I think a useful set of user options to provide are: Auto (emulator chooses based on preference if supplied, otherwise arbitrary), Prefer X (user chooses system X, it is used if supported and no preference is supplied, otherwise same as Auto), Force (user chooses and the supplied options are ignored).

The point of the preference was to indicate that there is one "best"version; if they can't get that every other supported version is some kind of compromise. I think it is splitting too fine a hair to want to rank those compromises too.


Legacy emulators won't support any of this, so I don't think they're a concern. (In some cases, providing multiple ROMs that differ only by header is a valid way to provide both options to users, too.)

[VEG]

Denoting what is preferred on the other hand is inherently subjective and therefore ambiguous.

It's not subjective. The preferred system is the system which works perfectly with the ROM. The other ones are supported, but not perfect. For example, in case of Unchained Nostalgia, in case of PAL you will have a slightly wrong sound on noise channel (because it is not possible to make it absolutely the same on three systems), in case of NTSC you may notice artifacts of speed adoption (it skips every 6th frame on NTSC systems to have the same speed as on Dendy). So, it is perfect only on Dendy, but it also works nicely on PAL and NTSC systems. That's why Dendy is preferred, but NTSC and PAL also are allowed. This bitfield is not for storing some settings by a user. It is intended to describe what is supported by the ROM, and what is the best option.

[NewRisingSun]

For example, in case of Unchained Nostalgia, in case of PAL you will have a slightly wrong sound on noise channel (because it is not possible to make it absolutely the same on three systems), in case of NTSC you may notice artifacts of speed adoption (it skips every 6th frame on NTSC systems to have the same speed as on Dendy). So, it is perfect only on Dendy, but it also works nicely on PAL and NTSC systems.

Then just denote it as "Dendy". I do not see the value of also denoting that it sort-of works on NTSC and PAL.

Addition:

It is intended to describe what is supported by the ROM

I faced a similar issue when designing my input device field: Do I want to describe all the things a ROM might support (turning the header into an "encyclopaedia about the game"), or merely what device an emulator must virtually plug in for the user to actually play the game, without using hash tables? After making the choice unambiguous for all games (the only one supported, or the default one in the case of several options), I chose the latter for a much more concise, easy-to-implement, space-saving field.

[Bregalad]

It's not subjective. The preferred system is the system which works perfectly with the ROM. The other ones are supported, but not perfect. For example, in case of Unchained Nostalgia, in case of PAL you will have a slightly wrong sound on noise channel (because it is not possible to make it absolutely the same on three systems), in case of NTSC you may notice artifacts of speed adoption (it skips every 6th frame on NTSC systems to have the same speed as on Dendy). So, it is perfect only on Dendy, but it also works nicely on PAL and NTSC systems. That's why Dendy is preferred, but NTSC and PAL also are allowed. This bitfield is not for storing some settings by a user. It is intended to describe what is supported by the ROM, and what is the best option.

It is suggestive. You call the sound on the noise channel "wrong", this is your opinion and it could be agreed otherwise. You say you notice artifacts of speed adoption, this is just your opinion.

[VEG]

I have not much to say about it as an iNES revision. I'll respond to the request to alter the 'regn' field though

According to NSFe, I propose to extend the meaning of the byte $0006 in the INFO section. regn section would not be required at all if the byte $0006 is extended in a backward compatible way.

Legacy emulators won't support any of this, so I don't think they're a concern.

Legacy emulators already treat two bits from this byte. So, if we extend this byte, we should take into account original meaning of these two bits. That's why you set Dendy as a preferred system and another system as a fallback. Some emulator which don't support Dendy at all, and it will have information which system should be used in this case, for example.

I think has ramifications that are an encumbrance on the implementation for how to correctly handle that ranking.

Actually, it makes things easier. Especially for cases when an emulator doesn't support Dendy and needs to fallback to NTSC or PAL. It will just use original meaning of bits 0 and 1, and voila! If Dendy is supported, just treat the byte as two nibbles which describe the same things as described in the regn section of the latest NSFe specification.

[VEG]

Then just denote it as "Dendy". I do not see the value of also denoting that it sort-of works on NTSC and PAL.

rainwarrior already has provided an example how to use this information:

I think a useful set of user options to provide are: Auto (emulator chooses based on preference if supplied, otherwise arbitrary), Prefer X (user chooses system X, it is used if supported and no preference is supplied, otherwise same as Auto), Force (user chooses and the supplied options are ignored).

You say you notice artifacts of speed adoption, this is just your opinion.

You can notice it when scrolling is used. It is not as smooth as it is when Dendy mode is used. The difference is subtle, but it exists and you can notice it.

[NewRisingSun]

rainwarrior already has provided an example how to use this information:

I asked about the value of this information, meaning the why, not the how. To put it bluntly: if it is supposed to be run on Dendy, then that is all the emulator needs to know --- who gives a shit if it also can be run on NTSC and PAL?

Addition:
As for the subjectivity part, I would not know whether some unlicensed games are "preferred" to run as NTSC or Dendy. For example, I know that because later Waixing games were sold in mainland China for the Subor famiclones, Dendy is the "correct" target platform, but listening to the music speed, I would "prefer" NTSC.

[VEG]

To put it bluntly: if it is supposed to be run on Dendy, who gives a shit if it also can be run on NTSC and PAL?

If an emulator don't support Dendy, it should know which system it should use. If a user prefers some specific system for some reason, but don't want to force it when it is not supported by a ROM, the information about supported systems would be useful for an emulator.

but listening to the music speed, I would "prefer" NTSC.

It doesn't matter what you prefer (but you can still "force" your preferred system). The only right music speed is on Dendy. In case of Unchained Melody it is easy to check. It's a cover to a well-known melody, and it is as slow as on the cover on Dendy.

[NewRisingSun]

If an emulator don't support Dendy, it should know which system it should use. If a user prefers some specific system for some reason, but don't want to force it when it is not supported by a ROM, the information about supported systems would be useful for an emulator.

Both being highly contrived scenarios.

It doesn't matter what you prefer (but you can still "force" your preferred system)

Okay, now I understand nothing. I am supposed to denote a preferred system, but it does not matter what I prefer?

[VEG]

Both being highly contrived scenarios.

Sometimes it is not easy to add Dendy support to an emulator. For example, it took a lot of time to add it to the FCEUX, because FCEUX had a lot of hardcoded things throughout the whole codebase. In this case, an emulator could use information provided.

I am supposed to denote a preferred system, but it does not matter what I prefer?

The header will provide the only right preferred system. You can force another system in the emulator if you wish, as it was written before.

[rainwarrior]

In the case of NSF, dual region was part of the spec from the beginning. The question of preference for the most part didn't come up; I think Streemerz was the first dual region that had a reason to prefer PAL, and it's probably the only such NSF worth talking about still. It probably should have been exclusive (as should have the expansion fields too) but this is its history.

I don't really want to implement this thing you thought of. OK it's "backwards compatible" with the previous one, that's a nice property for an addition to have, but that's not a reason that we need to stuff yet another thing into the NSF specification. I created 'regn' and implemented it. I don't really want to assist creating another redundant way to do this. All this proposal does is making parsing more complicated, without really adding anything that was needed.


For iNES, I do think it's important to put region in there, but that's the only critical thing to me. The rest is decreasingly useful. I only put preference into NSFe because it's an inherently extensible format, it's an entirely optional addition to the file. Not really comparable to iNES.

[NewRisingSun]

Well, FCEUX has since added Dendy support, and I know of no other major emulator without Dendy support. The scenario is still highly contrived because it requires adding support for the proposed field without also adding support for Dendy timing.

Sometimes it is not easy to add Dendy support to an emulator.

Additional header fields should not be added for the sake of helping emulator authors avoid implementing necessary features.

The header will provide the only right preferred system. You can force another system in the emulator if you wish, as it was written before.

I am getting completely confused by your use of the term "preferred". Preferred by whom?

I think you mean to say "Dendy is correct, but the game can also run without serious glitches on NTSC/PAL as a second-best option". That might be less subjective, but we still have the problem that this information is more encyclopaedic than useful:

If a user prefers some specific system for some reason, but don't want to force it when it is not supported by a ROM

A user wants to run a game on an emulated console it was not made for? Who does that? Highly contrived, and does not justify adding a header field. The only application I see for this is running PAL/Dendy games at 60 Hz for better VSync purposes, and there are better ways of achieving that in an emulator.

[Bregalad]

I asked about the value of this information, meaning the why, not the how. To put it bluntly: if it is supposed to be run on Dendy, then that is all the emulator needs to know --- who gives a shit if it also can be run on NTSC and PAL?

All ROMs can be run with NTSC, PAL and Dendy. It's just that the results might be disastrous, for example running Battletoads PAL on NTSC will not get the games running, but you can still do it.

It's not part of the ROM on which system it's run - the ROM is a digital represntation of the cartridge. Lockout chips makes it possible to objectively say which video system the cartridge should be used on. But for unlicenced games there's no such a thing - anything will be subjective.

[VEG]

The scenario is still highly contrived because it requires adding support for the proposed field without also adding support for Dendy timing.

Wrong. This field is already supported by the emulators which know about NES 2.0. For example, look at this code from the Mesen (before it adopted your suggestion):

Code: Select all

	bool IsPalRom()
	{
		switch(GetRomHeaderVersion()) {
			case RomHeaderVersion::Nes2_0: return (Byte12 & 0x01) == 0x01;
			case RomHeaderVersion::iNes: return (Byte9 & 0x01) == 0x01;
			default: return false;
		}
	}

Or another example from its debugger:

Code: Select all

			public bool IsPalRom()
			{
				switch(GetRomHeaderVersion()) {
					case RomHeaderVersion.Nes2_0:
						return (_bytes[12] & 0x01) == 0x01;
					case RomHeaderVersion.iNes:
						return (_bytes[9] & 0x01) == 0x01;
					default:
						return false;
				}
			}

If my suggestion is included into the NES 2.0 spec, all old emulators which used similar code would work exactly as it was designed before. That's why this "legacy behavior" exists in my proposition. The thing that an emulator which doesn't support Dendy mode could use the fallback behavior is just a nice addition to the backward compatibility.

I am getting completely confused by your use of the term "preferred". Preferred by whom?

There is a preferred system which is selected in the ROM, there is another preferred system which may be selected by the user. rainwarrior has provided a description of behavior of an emulator:

I think a useful set of user options to provide are: Auto (emulator chooses based on preference if supplied, otherwise arbitrary), Prefer X (user chooses system X, it is used if supported and no preference is supplied, otherwise same as Auto), Force (user chooses and the supplied options are ignored).

In other words: There is a list of supported systems by ROM, and a preferred system selected in the ROM. A user of an emulator can choose a preferred system in the settings of the emulator: Auto, NTSC, PAL, Dendy, Force NTSC, Force PAL, Force Dendy. If the user specified Auto (and it is the default behavior), emulator will always use the preferred system specified in the ROM itself. If the user chooses NTSC/PAL/Dendy as preferred, the emulator checks if the preferred system by user is supported by ROM, and if it is, it will use the preferred by user system. Otherwise, it will use preferred by ROM system. And if the user chooses to force NTSC/PAL/Dendy, the emulator just ignores the byte in the header and always used the forced system.

I think you mean to say "Dendy is correct, but the game can also run without serious glitches on NTSC/PAL as a second-best option". That might be less subjective, but we still have the problem that this information is more encyclopaedic than useful

If the ROM has specific code to work properly on all known systems (it detects current system and makes some adjustments), it is not a useless information. Even in this case there could be just one the best option, because it is not possible to make exactly the same behavior on all the supported systems. Just not possible and that's it.

A user wants to run a game on an emulated console it was not made for? Who does that? Highly contrived, and does not justify adding a header field.

It is a normal use case. If you don't do it, it doesn't mean that nobody else does it. A lot of people played NTSC games on Dendy in their childhood. And sometimes they prefer to play these games with the same timings even nowadays, and they don't care that the games weren't designed for Dendy. I can say even more. Sometimes they buy a Famicom and modify it to use a chipset from a famiclone with Dendy timings, to play a Famicom with Dendy timings. That's why there should be a possibility to force any system, even when a ROM doesn't support it.

Highly contrived, and does not justify adding a header field.

It is not adding a new field, it is using an existing one.