NES 2.0 Additions Proposal

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

For the controller byte, would it be a good idea to use the high bit to distinguish between games where the controller is required versus games where it is optional? That still gives you 128 possibilities for controller assignments. The idea is to allow emulators to notify the player of an option and ask if they'd like to use it.

I have observed how Nestopia "emulates" R.O.B. It only emulates a portion of R.O.B.'s functionality, namely using the start button to send commands allows buttons A and B on controller two to remain pushed down. Ideally, for either game R.O.B. would be emulated in a second window, where you could see the robot do its thing and his hands and the gyros would be animated. But for Stack-Up, R.O.B. could be easily simulated by writing a little puzzle application in which you can use a cursor to move colored "blocks" in the way R.O.B. can, from the bottom Block you select. R.O.B. has no trouble moving all five Blocks in reality as shown in Jeremy Parish's videos. For U-Force, I think you might be able to get away with using a Wiimote, but for the Power Glove you would need something like a Kinect because the Glove can recognize finger movements. Emulators will ultimately only recognize what they can support.

Also, for Smash TV, I noted that both the NES Satellite/Four Score or the Double-Fisted categories apply to the game, but NES 2.0 only allows you to select one option. I would suggest ditching the double fisted option for this game because the game allows you to use one or two controllers to control each character and clearly indicates it in the game options menu. Crazy Climber requires Double-Fisted control, but it may not be instantly obvious on running the game.

The TV System byte, if strictly enforced, could lead to revisiting most of the "black box" games' ROM headers, as they typically did have PAL-optimized releases. ROMs with the (World) or (USA, Europe) designations would be eligible for designation.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

I agree that a Kinect sensor would be closer to ideal for the Power Glove, as it senses the position of the hand rather than its direction. However, I'd wager that mapping the thumb to the Wii Remote's A button and the other fingers to B should allow existing Glove-aware software to run.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

I have now rewritten the wiki NES 2.0 page for brevity and added the content of this proposal, hopefully incorporating all points that were made and agreed-upon. Thanks to everybody who participated in the discussion!
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: NES 2.0 Additions Proposal

Post by zeroone »

Great Hierophant wrote:I have observed how Nestopia "emulates" R.O.B. It only emulates a portion of R.O.B.'s functionality, namely using the start button to send commands allows buttons A and B on controller two to remain pushed down. Ideally, for either game R.O.B. would be emulated in a second window, where you could see the robot do its thing and his hands and the gyros would be animated. But for Stack-Up, R.O.B. could be easily simulated by writing a little puzzle application in which you can use a cursor to move colored "blocks" in the way R.O.B. can, from the bottom Block you select. R.O.B. has no trouble moving all five Blocks in reality as shown in Jeremy Parish's videos. For U-Force, I think you might be able to get away with using a Wiimote, but for the Power Glove you would need something like a Kinect because the Glove can recognize finger movements. Emulators will ultimately only recognize what they can support.
For Gyromite and Stack-Up, try Nintaco. It also supports the U-Force.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: NES 2.0 Additions Proposal

Post by zeroone »

NewRisingSun wrote:I have now rewritten the wiki NES 2.0 page for brevity and added the content of this proposal, hopefully incorporating all points that were made and agreed-upon. Thanks to everybody who participated in the discussion!
Thanks for spearheading these changes. Some of the stuff below is based on our PMs.

Regarding VS Hardware type, can the header specify the exact VS game? Currently, I see RBI Baseball, TKO Boxing, Super Xevious, Ice Climber, and Raid on Bungeling Bay listed there. And there aren't that many VS titles. Since the DIP switch settings are not specified in the header, the emulator will need to figure out which VS game it is anyway (through some other checksum means).

This may have come up earlier in the thread (I have yet to read through it entirely), but the Default Expansion Device list seems incomplete. E.g. if the default is R.O.B., is that R.O.B. setup for Gyromite or Stack-Up? For the Zapper, which is the default port? I also see U-Force is not listed. The prototype game does tap into it's analog abilities, suggesting that it should be on the list. If there is an option for 2 SNES controllers, why not toss the SNES mouse into the mix as well.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

zeroone wrote:can the header specify the exact VS game?
No, and I don't see why it should. It's only designed to specify PPU type and other protection, which not all games use. If you care about DIP Switches, that is not something for the Vs. Type field, as non-Vs. games can have DIP Switches as well.
zeroone wrote:E.g. if the default is R.O.B., is that R.O.B. setup for Gyromite or Stack-Up?
Gyromite. I only added it because Nestopia can be made to press the 2P controller buttons like R.O.B. would. As discussed a few pages earlier, Stack-Up's blocks are not really something suitable for an emulator, unless you want to create a three-dimensional display of multi-colored blocks.
zeroone wrote:Zapper, which is the default port?
Famicom expansion port, which translates to 2P on NES.
zeroone wrote:I also see U-Force is not listed.
I have added it.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

If you're doing Dualsystem, then you have to have two views anyway. The same is true of Wide Boy with Game Link. I guess the "three-dimensional display of multi-colored blocks" could appear in the second view for a R.O.B. game.
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: NES 2.0 Additions Proposal

Post by zeroone »

NewRisingSun wrote:Gyromite. I only added it because Nestopia can be made to press the 2P controller buttons like R.O.B. would. As discussed a few pages earlier, Stack-Up's blocks are not really something suitable for an emulator, unless you want to create a three-dimensional display of multi-colored blocks.
Nintaco already renders R.O.B. in a separate window. And that view is different for Gyromite and Stack-Up. In fact, for Stack-Up, the player normally hits Start after completing the block arrangement (it's the honor system). But Nintaco monitors the game state by peering into CPU RAM and it triggers Start automatically at that time (as if R.O.B can see what you're doing).

Specification of the R.O.B. configuration is far more valuable than just "plug in R.O.B.".
tepples wrote:If you're doing Dualsystem, then you have to have two views anyway. The same is true of Wide Boy with Game Link. I guess the "three-dimensional display of multi-colored blocks" could appear in the second view for a R.O.B. game.
Nintaco uses 2 views for things other than R.O.B. such as the 3D glasses. I'm still thinking about the best way to present the VS DualSystem, if I ever get that working. I'd much rather prefer that to be a Netplay exclusive where each emulator was the view.

I just looked up the Wide Boy. I had no idea that existed. Since the NES is only used as a pass-through device, it sounds a bit ridiculous to emulator/simulate that for an NES emulator.
NewRisingSun wrote:No, and I don't see why it should. It's only designed to specify PPU type and other protection, which not all games use. If you care about DIP Switches, that is not something for the Vs. Type field, as non-Vs. games can have DIP Switches as well.
I understand. But it's unfortunate that a Cart DB will still be required even with this new header system. As soon as extra cart data needs to be stored in a table within the emulator anyway, all the other stuff in the header can be stored along with it. Unless the header really contained 100% of the data required to run the game properly, the Cart DB is going to be the preferred authority. Of course, if a particular game is not in the Cart DB, the more data available in the header the better.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

I do not accept that you need DIP switch documentation to run a game properly. All games that I am aware of can absolutely be played properly even if you don't know what every DIP switch setting means. Without a database, depending on the Console Type/Mapper PCB that defines whether there are DIP switches at all, you could present the user with unlabelled DIP switch controls, as many emulators already do. I do not quite see the difference between labelling DIP switch controls and, say, labelling memory locations, for cheating or any other purpose. Surely nobody would ask to include labels for memory locations in a ROM image file! Therefore, I consider DIP switch documentation non-essential, while Mapper variant or default expansion device information are essential, for playing a game.
zeroone wrote:As soon as extra cart data needs to be stored in a table within the emulator anyway, all the other stuff in the header can be stored along with it.
It could, but why should it?

That being said, I am not opposed in principle to including DIP Switch labels in a .NES file. I just consider it impractical, no, impossible to do so while keeping the entirety of a .NES file unambiguous, so that DAT projects such as No-Intro can start indexing complete .NES files including headers. Text fields are inherently subjective, with different punctuation, spacing, capitalization, romanization all encoding the same information correctly yet differently. I have seen this with NSF files --- the exact same file exists in up to three different variations, differing in the title/author/copyright fields alone, without any one of them being "incorrect".
zeroone wrote:Specification of the R.O.B. configuration is far more valuable than just "plug in R.O.B.".
It does not say "plug in R.O.B.", it says "R.O.B. Gyro set". An entry for "R.O.B. Stack-Up" could be added, but I would have to see what such an emulation would look like.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 Additions Proposal

Post by rainwarrior »

After seeing how Mesen has implemented, I have a request for Byte 15:

Add a value for "do not override user settings" or something of that nature. This is needed for stuff like tepples' "allpads" or other situations where it's deliberately wanted for the user to plug in what they like.

The current default for Mesen is to basically stomp on all custom input settings if there is an iNES 2.0 header, because "00" was used to mean standard controllers, and this seems more like an unfortunate consequence of this specification, rather than a bug in Mesen, like that really seems what the emulator should do according to the spec.

Wish this value could have been $00, but I hadn't noticed this consequence until seeing it in action now. :( In general adding anything new to the iNES 2 spec where $00 introduces a new behaviour is not good, IMO. Feels like an accident that this spec results in new behaviour, but I think it does manifest that way.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

I had originally called value $00 "unspecified, use standard controllers", assuming that an emulator will default to standard controllers when loading a ROM without any information on the expected input device, having observed that Nestopia (I think) does that if it cannot find a ROM in its internal database. That is why I defined no separate values for "unspecified" and "standard controllers". I am not quite convinced that this should be changed --- whoever selects an input device before loading a ROM? For "allpads", I would load the ROM, causing the emulator to default to standard controllers, then for every device that I want to test with "allpads", select it from the emulator's menu (which the spec explicitly calls for to be possible), then Soft-Reset. So I am not sure what an allpads setting would do, or why standard controllers needs to be separate from unspecified.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 Additions Proposal

Post by rainwarrior »

I would suggest the definition be more open, something closer to just "no information about controllers", and leave it at that. $00 should explicitly mean that the author either doesn't know or hasn't filled in this field; all older iNES 2 ROMs are already leaving $00 here because it was reserved.

Using standard controllers, or assuming user input is consequential behaviour from there being no information, but what should be done really depends on the emulator author's goals etc. I think, shouldn't have to be called out in the spec.


Allpads is tepples' input emulator test ROM: https://wiki.nesdev.com/w/index.php/Emu ... nput_Tests

The point of that ROM is to figure out what you have connected. Obviously this ROM would never want to specify which controllers to use. This is the most extreme counterexample of why $00 implying standard controllers is bad, but this will more weakly also be a problem for any homebrew game that wanted special controllers and was using iNES 2 header before this was specified.


Otherwise I do think it would actually be good to have an explicit specification for "standard controllers" too, and probably that would be the one we should use most often, since that's what most games need, but if e.g. that option was $01 it would mean "this game is known to require standard controllers" and $00 would mean "no information about controllers".
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

"Standard controllers" cannot be $01 unless everything else moves down one number. Some recent ROM images already use that field, and I do not want to invalidate or replace them.

I actually have no problem at all with value $00 having a definite interpretation in NES 2.0, and the Default Expansion Device field is not alone in that regard: a NES 2.0 PRG/CHR-RAM value of $00 definitely causes a difference compared to iNES, as anybody who has ever naively converted an UNROM game can attest. The same goes for the TV System byte. In fact, I cannot think of any other NES 2.0 field where value $00 really means "no information", and in my stated interest of avoiding ambiguity, I don't really want to introduce one. (That's why I now take back the word "unspecified" that is not on the wiki, but was part of the draft earlier in this thread.)

Defining "$00" as standard controllers would only invalidate ROMs that already are NES 2.0 but were released as such before the specification update and need something other than standard controllers. The vast majority of NES ROMs are iNES, and most of the few NES 2.0 ROMs that have been released would not have set this field to anything other than $00 Standard Controllers anyway. On the other hand, defining Standard Controllers as anything other than $00, and defining $00 as "no information" would mean that the majority of released NES 2.0 ROMs would become underspecified with one stroke.

So therefore, I continue to oppose defining value $00 as anything other than standard controllers. I will gladly add a device value for "allpads", though I would want a better description than "do not override user settings", more like a generic description of what it is instead of specific instructions on the consequences that the emulator should take. "Any"?
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: NES 2.0 Additions Proposal

Post by Sour »

rainwarrior wrote:After seeing how Mesen has implemented, I have a request for Byte 15:

Add a value for "do not override user settings" or something of that nature. This is needed for stuff like tepples' "allpads" or other situations where it's deliberately wanted for the user to plug in what they like.
FYI, you can disable byte 15's behavior by disabling the "Automatically configure controllers when loading a game" option in the input options. This disables using both the game database and byte 15 to select controllers.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

The test screen you see depends on the type of controller you connect. It's not unlike the situation with Super Mario Bros./Duck Hunt/World Class Track Meet. So would the definition of "multicart" fit?
Post Reply