NES 2.0 Additions Proposal
Moderator: Moderators
Re: NES 2.0 Additions Proposal
Headers should describe the cartridge. There is nothing in a game cartridge that inherentely uses one controller, two controllers, a zapper or whathever. It's how the user wires this up when booting the game. So this information (which "input" a game supports) has nothing to do in a NES header.
Re: NES 2.0 Additions Proposal
Bregalad, we've already had that argument, and we've already discarded it as self-contradictory.
Please re-read starting here: https://forums.nesdev.com/viewtopic.php ... 28#p227528
Please re-read starting here: https://forums.nesdev.com/viewtopic.php ... 28#p227528
Re: NES 2.0 Additions Proposal
Probably not many, seeing as expansion controllers other than the Zapper aren't exactly common, and TVs supporting the Zapper without a LightGunVerter are on the decline in the NES 2.0 era. One could argue that Family BASIC and Family BASIC V3 may count, as their RAM size is 2 KiB or 4 KiB respectively, not the 0 or 8 KiB implied by original iNES, and they require a keyboard. The best bet is probably educational cartridges requiring a famiclone keyboard and using mapper 256+.NewRisingSun wrote:Which games were released in NES 2.0 format that do require something other than standard controllers?
Three more are Zap Ruder, Sliding Blaster, and the sound effects editor included with Pently. But these five aren't quite ideal examples for two reasons. First, none of these requires the additional features of NES 2.0 compared to iNES, unlike (say) The Curse of Possum Hollow which requires the extra CHR RAM. Second, like the commercial-era games Arkanoid, Baby Boomer, and Operation Wolf, all five of these programs gracefully degrade when the expected expansion controller isn't present.rainwarrior wrote:but let's start with allpads and thwaite.
I find this unconvincing. The box art of Videomation states: "Not A Game! A Drawing and Animation System!" Do we want to exclude products like Videomation from consideration when building a way of representing all NES software?NewRisingSun wrote:one of which is not a game
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES 2.0 Additions Proposal
The emulator doesn't gracefully degrade, however. You can have prior settings to set up your custom user input configuration to use the zapper or mouse, but the specification of "this ROM uses standard controllers" can override them, because it thinks these ROMs are specifying that. These need to be at worst unspecified, not specified as their non-ideal fallback configuration. At best we'd be able to use this byte 15 to specify they have special needs... which is why this byte was a good idea and really deserves to be there.tepples wrote:these programs gracefully degrade when the expected expansion controller isn't present.
Right now, Mesen will stomp your settings on every power-on (which reloads the ROM, reparses the header, and re-overrides the settings), which is very bad. Sour could work around this by keeping track of whether you've ever made settings changes on a per game solution, maybe, but I think that's complicated an error prone, and not a good solution. The problem is merely caused by $00 no longer meaning "unspecified" as it always did in the past. Restoring that is the simplest fix for this.
...and doing so would make Mesen's current behaviour into a good implementation. It should stomp your settings if you have that option enabled and the ROM has specified what it needs.
Re: NES 2.0 Additions Proposal
I too am currently in favor of $00 meaning un(der)specified and/or bit 7 having something to do with ability to fallback to standard controllers.
Re: NES 2.0 Additions Proposal
(Disclaimer: I did not read every single reply on this issue completely)
I agree the current behavior is probably not ideal since it can be annoying for older NES 2.0 roms (although changing it now means it's annoying for the newer NES 2.0 roms)
Bit annoying that this results in having older roms on the old spec + newer roms on the newer spec, with no way to distinguish between them. Although I suppose that is partially my own fault for implementing it so early.
In an ideal world where existing roms all get fixed with no effort, I guess having $00 as a "nothing specified, don't change inputs" and $01 as "standard controllers" would make the most sense (e.g offset all the current entries by 1 and change the meaning for $00).
Alternatively, I suppose $FF could be used as a "nothing specified" value, if that makes it less annoying to change.
I agree the current behavior is probably not ideal since it can be annoying for older NES 2.0 roms (although changing it now means it's annoying for the newer NES 2.0 roms)
Bit annoying that this results in having older roms on the old spec + newer roms on the newer spec, with no way to distinguish between them. Although I suppose that is partially my own fault for implementing it so early.
In an ideal world where existing roms all get fixed with no effort, I guess having $00 as a "nothing specified, don't change inputs" and $01 as "standard controllers" would make the most sense (e.g offset all the current entries by 1 and change the meaning for $00).
Alternatively, I suppose $FF could be used as a "nothing specified" value, if that makes it less annoying to change.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES 2.0 Additions Proposal
No, $00 has to be that. There is no other way to ensure compatibility with older iNES 2 ROMs. The rest of the possible values for byte 15 don't affect compatibility with old ROMs.Sour wrote:Alternatively, I suppose $FF could be used as a "nothing specified" value, if that makes it less annoying to change.
The other values in the list don't necessarily have to change at all. If we need a way to specify "this ROM needs standard controllers", another value can be added to the list, but it shouldn't be $00.
If you want to reorganize the list and replace $01, etc.... that's a different effort that would need to be coordinated with NewRisingSun (if they haven't given up entirely on this) or whomever is trying to use it to prepare ROMsets. I'm indifferent to whether the rest of the list changes at this point, because I'm not involved in such stuff, but none of the existing values except $00 have to change to solve any practical problem here. I'm assuming it would be nicer if the ROMset release NewRisingSun was referring to doesn't get broken by a list reorganization.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: NES 2.0 Additions Proposal
What part of "disavow" do you not understand?rainwarrior wrote:that's a different effort that would need to be coordinated with NewRisingSun (if they haven't given up entirely on this)
Not that I care at this point, but "Famicom controllers with Microphone" ($01) is not an expansion device. It is a standard feature of the Famicom console. It should not have been in the list and could be replaced without moving the other items around.Sour wrote:and $01 as "standard controllers" would make the most sense (e.g offset all the current entries by 1 and change the meaning for $00).
Is it too much to ask to actually read a thread before excreting a moronic drive-by comment like yours that has already been debated to death?! Apparently so.Bregalad wrote:Headers should describe the cartridge. (..) So this information (which "input" a game supports) has nothing to do in a NES header.
Re: NES 2.0 Additions Proposal
In this case, the "expansion" involves switching from an AV Famicom, which lacks a microphone and has Select and Start on controller 2, to an RF Famicom, which has a microphone and lacks Select and Start on controller 2.NewRisingSun wrote:"Famicom controllers with Microphone" ($01) is not an expansion device. It is a standard feature of the Famicom console. It should not have been in the list and could be replaced without moving the other items around.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: NES 2.0 Additions Proposal
But it is not an expansion device. If distinguishing different console types/variants is desired, the console type field should be used for that. Doing so is unnecessary though --- it is perfectly adequate to simultaneously emulate and allow the user to define keys for both Microphone and 2P START+SELECT, as the bits do not overlap.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES 2.0 Additions Proposal
The microphone is part of a controller, and it goes through the same interface as all other controllers. It think it was a good idea to keep it in the controller field with the other controllers.
Yes, it was hardwired to a particular model of Famicom, but really it can be plugged into any of the machines with a suitable simple adapter. This is really just a question of what D2 is connected to. ...and for an emulator choosing an input set to emulate, this really doesn't help to be tied to console setting at all. Though yes the best thing to emulate is usually a combo controller with both START and Microphone, internally.
...and it's good information! Ideally the microphone port should be mapped to an actual microphone to simulate the experience, but it may not be practical for an emulator to look for / demand / actively listen for an attached microphone at all times. (E.g. think of a web based emulator having to ask permission to use the microphone: should want to do this sparingly.) This is helpful for that need. An ideal simulation of the experience needs the microphone signal (maybe even with feedback into the sound return), and not just a button press as a minimal replacement.
"This game uses the microphone" is just good data to have. My opinion is that mic was a very good inclusion in this field.
"This game ignores START on controller 2" on the other hand isn't particularly useful, IMO. There's not much need to ever simulate that part of it.
Yes, it was hardwired to a particular model of Famicom, but really it can be plugged into any of the machines with a suitable simple adapter. This is really just a question of what D2 is connected to. ...and for an emulator choosing an input set to emulate, this really doesn't help to be tied to console setting at all. Though yes the best thing to emulate is usually a combo controller with both START and Microphone, internally.
...and it's good information! Ideally the microphone port should be mapped to an actual microphone to simulate the experience, but it may not be practical for an emulator to look for / demand / actively listen for an attached microphone at all times. (E.g. think of a web based emulator having to ask permission to use the microphone: should want to do this sparingly.) This is helpful for that need. An ideal simulation of the experience needs the microphone signal (maybe even with feedback into the sound return), and not just a button press as a minimal replacement.
"This game uses the microphone" is just good data to have. My opinion is that mic was a very good inclusion in this field.
"This game ignores START on controller 2" on the other hand isn't particularly useful, IMO. There's not much need to ever simulate that part of it.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: NES 2.0 Additions Proposal
No. It's not "good information" --- a player should not be alerted by the emulator that he may now use the microphone to trigger a hidden game function with the game he is about to load. If the microphone is to be emulated with an actual microphone, the emulator can ask for permission once such a means of emulation is actively selected by the user. Therefore, the Famicom microphone can and should be emulated at all times, or at least for as long as the user has defined a key or other trigger, and list item $01 can be removed, to be replaced with standard controllers.
I see. You are not too indifferent to sabotage the entire effort, but you are too indifferent to help fix the mess you have created.rainwarrior wrote:I'm indifferent to whether the rest of the list changes at this point, because I'm not involved in such stuff
Last edited by NewRisingSun on Sat Jan 12, 2019 12:48 pm, edited 6 times in total.
Re: NES 2.0 Additions Proposal
@NewRisingSun In your VS UniSystem NES 2.0 ROM set, I noticed some games had padded versions. For instance, the PRG ROM size for Vs. Tetris (padded).nes is 32768 bytes, while Vs. Tetris.nes is only 24576 bytes. My emulator has difficulty dealing with PRG ROM sizes that aren't powers of 2 (without sneaking in some additional game-specific logic). What's the general approach to padding and will it work for all the games?
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: NES 2.0 Additions Proposal
NewRisingSun wrote:No. It's not "good information" --- a player should not be alerted by the emulator that he may now use the microphone to trigger a hidden game function with the game he is about to load.
...and that's really aside from the issue that the emulator needs to know about it, and really so does the user. Some computers have a microphone attached all the time, but many have none.
It's really absurd to think that someone with no microhpone on their computer is going to somehow discover a hidden game function that requires a microphone. This is an extra peripheral you have to add, and you have to know about. Aside from a few very ideal emulator setups (e.g. Wii U VC with a mic guaranteed built into the pad) there is not much hope for this dream of accidentally discovering it naturally, and it's a torpedo to every other game that actually just legit needs the mic for a real and non-secret purpose.
No, it's not really entirely practical for an emulator to emulate the microphone at all times. It may be for some, but this is helpful information.NewRisingSun wrote:Therefore, the microphone can be emulated at all times, and list item $01 can be removed, to be replaced with standard controllers.
It was in the spec you offered a few days ago though. Are you trying to argue for its removal just to free up $01 to stick standard controller spec into? If you want to reassign microphone to another value I personally have no problem with that. Why were you happy with microphone in the spec a few days ago when you pushed the wiki edit and not now?
This is not a personal vendetta. I already think I responded to this about as clearly as I can in this post, which outlines my motivations for caring about the value of $00. What mess has been created, and what help are you asking for to fix it?NewRisingSun wrote:I see. You are not too indifferent to sabotage the entire effort, but you are too indifferent to help fix the mess you have created.rainwarrior wrote:I'm indifferent to whether the rest of the list changes at this point, because I'm not involved in such stuff
I am not involved in making ROMsets, so I can't possibly know what you have prepared looks like, or why it's a "mess". As far as I understand, the reversion of the meaning of just $00 should affect a published ROMset in an almost completely benign way. If there is something more to it you're going to have to explain that. I've tried very hard to explain why changing $00 to be a specification for standard controllers creates a problem for many older iNES 2 homebrew.
I'm definitely not trying to "sabotage the entire effort". Please look at the things I have said. I am very much in favour of this field. I am trying to fix value $00, which created a new problem. The rest was good, and I very much want it to stay. I want the ROMsets to be able to use it too.
Last edited by rainwarrior on Sat Jan 12, 2019 1:57 pm, edited 1 time in total.
-
- Posts: 1510
- Joined: Thu May 19, 2005 11:30 am
Re: NES 2.0 Additions Proposal
Oh, forget about attaching a microphone to a computer. No NES emulator even supports that, and even if there was one, it's an utterly esoteric configuration for a NES emulator. This is all about mapping a key on your keyboard/joystick, such as "M", to $4016 bit 2. That is all. And that can be done at all times. No game suffers from that, and neither does the emulator. A real RF Famicom hardware player can blow into his 2P microphone at all times, so an emulator user should be able to trigger the microphone bit at all times.
Have you actually researched the Famicom microphone? Almost no game explicitly advises the player to use the Famicom microphone, and almost all of them use it to trigger cheats, as a puzzle solution for the player to find out, or to trigger an easter egg. Bakushou Jinsei Gekijou may be the only ones where the microphone use is explicitly instructed to the player. Conveying microphone use in the header reveals something to the player that the player was originally expected to find out himself. It is basically a spoiler. The NES header is no place for spoilers.rainwarrior wrote:It's only "hidden" in Zelda, and even then there is not a lot of mystery to preserve at this point. Other microphone uses in Famicom games were very explicit about it.
Oh sure, turn the table and ask me stupid questions. I became unhappy as soon as I went through the list of games that would have to receive the $01 byte, and noticed that when I read the "Input Device: Famicom Microphone" text in the emulator's status window, that I would be prompted to immediately try it out to find out what it does in that game. I did not change it because I considered it too late for that.rainwarrior wrote:Why were you happy with microphone in the spec a few days ago when you pushed the wiki edit and not now?
Is that not what I wrote?rainwarrior wrote:Are you trying to argue for its removal just to free up $01 to stick standard controller spec into?
The general approach to padding is to fill up an unusually-sized ROM with either a repeat of the data or with a filler byte until it reaches a size that allows an emulator to load the usually-sized ROM normally. The NES 2.0 spec says that 24 KiB Vs. ROMs (or halves for Vs. Dual) should be mapped to $A000-$FFFF, so if your emulator is confused by that, then you pad the ROM with 8192 bytes at the beginning so your emulator can find a normal 32 KiB PRG-ROM that it will load, as usual, to $8000-$FFFF.zeroone wrote:What's the general approach to padding and will it work for all the games?