It is currently Thu Nov 14, 2019 1:49 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 225 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15  Next
Author Message
PostPosted: Sat Jan 12, 2019 5:25 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 1023
zeroone wrote:
That didn't seem to work. I tried all 8 possibilities and none of them did the job.
Here is my code:
Code:
      if (RI.INES2_VSFlags ==VS_ICECLIMBERJ) {
         dynamic_cast<StdPort_StdController*>(Port1)->State->NewBits |=0x08;
         dynamic_cast<StdPort_StdController*>(Port2)->State->NewBits |=0x08;
      }      
Apparently, it has to be on both ports.
rainwarrior wrote:
And some will always disagree, they should still get to say that.
Oh sure. And I get to express my frustration at people who drive-by post something that has already been addressed before.
rainwarrior wrote:
I just put the word tentative in there so we can wait for assent from others. I think it will work, I don't know if someone is going to have an unexpected complaint about it. A little bit of time to allow that is needed!
Pretty much everybody else in the emulation community seems to have operated in the past twenty years according to the principle: Do first, document for everyone else later (maybe), coordinate with others never. Just look at FCEUX and all the other emulators who just "do things their way". So I think I am being more than cooperative, and after six months of comment solicitation and caving to a post-finalization complaint, my patience has worn thin. But if I look at some of the ludicrously bureaucratic ideas people had in the past, with having "numbered memos" signed by all emulator authors before allocating a new mapper number, I suppose I should be... grateful? Anyway, tentative will no longer be tentative Monday night.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 5:53 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7628
Location: Canada
Yeah sure, if nobody else comments on it by monday night I'd say that's perfectly reasonable.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 6:44 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 733
NewRisingSun wrote:
What is your opinion on whether to always having a key->$4016.2 mapping active vs. only if specified by a $F Mic field value?
At the moment Mesen automatically enables the microphone key when in "Famicom" mode, I don't really see myself removing the key binding from the UI/etc based on whether or not the ROM specifies that a microphone can be used (that would just make discovering that you can bind a key for the microphone port harder for the end user).

I can understand that it might be useful information to know that a game can use the 2P microphone (which is the same general goal as the rest of the entries in the list), but I'm not really sure what having the information would change from an emulator's perspective in this particular case (e.g what is the emulator supposed to do in this scenario? Since the ROM has the system set to Famicom, the emulator should presumably already have the microphone "plugged in", either way)


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 6:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7628
Location: Canada
My thought was that there's a very real overhead consequence for listening to an actual microphone device from a PC, and it's probably not something that should be "always on" for an emulator.

The current commonly used "map it to a key" implementation doesn't really have any overhead, so I don't think there's anything meaningful to do for that either. That one is fine as always on.

Whether anyone but me thinks this is an important possibility, I don't know.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 7:19 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 929
Location: New York, NY
NewRisingSun wrote:
Here is my code:
Code:
      if (RI.INES2_VSFlags ==VS_ICECLIMBERJ) {
         dynamic_cast<StdPort_StdController*>(Port1)->State->NewBits |=0x08;
         dynamic_cast<StdPort_StdController*>(Port2)->State->NewBits |=0x08;
      }      
Apparently, it has to be on both ports.


I gave that a shot, but it still doesn't work. However, I noticed that if I OR it with 0x01 instead, the game starts. But that causes other controller issues.

I know that the ports are swapped in this game. Was there some sort of individual bit swapping that I missed?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 7:30 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 1023
It's difficult to tell. It's usually best when your emulator has a simple debugger to know where the game hangs. Vs. Ice Climber uses the "Vs. System with reversed inputs" device, which means that D-Pad and A/B are reversed between $4016 and $4017. But that should have nothing to do with protection.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 7:32 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8668
Location: Seattle
MAME says:
Quote:
Code:
static INPUT_PORTS_START( vsnes )
        PORT_START("IN0")
        PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_BUTTON2 ) PORT_PLAYER(1)    /* BUTTON A on a nes */
        PORT_BIT( 0x02, IP_ACTIVE_HIGH, IPT_BUTTON1 ) PORT_PLAYER(1)    /* BUTTON B on a nes */
        PORT_BIT( 0x04, IP_ACTIVE_HIGH, IPT_START1 )            /* SELECT on a nes */
        PORT_BIT( 0x08, IP_ACTIVE_HIGH, IPT_UNKNOWN )           /* START on a nes */
[...]
static INPUT_PORTS_START( vsnes_rev )
        PORT_INCLUDE( vsnes )

        PORT_MODIFY("IN0")
        PORT_BIT( 0x01, IP_ACTIVE_HIGH, IPT_BUTTON2 ) PORT_PLAYER(2)    /* BUTTON A on a nes */
        PORT_BIT( 0x02, IP_ACTIVE_HIGH, IPT_BUTTON1 ) PORT_PLAYER(2)    /* BUTTON B on a nes */
[...]
static INPUT_PORTS_START( iceclimb )
        PORT_INCLUDE( vsnes_rev )
[... blah blah dip switch settings but no controller changes ... ]

/* Same as 'iceclimb', but different buttons mapping and input protection */
static INPUT_PORTS_START( iceclmbj )
        PORT_INCLUDE( iceclimb )

        PORT_MODIFY("IN0")  /* IN0 */
        PORT_BIT( 0x08, IP_ACTIVE_LOW,  IPT_CUSTOM )       // protection /* START on a nes */

        PORT_MODIFY("IN1")  /* IN1 */
        PORT_BIT( 0x08, IP_ACTIVE_LOW,  IPT_CUSTOM )       // protection /* START on a nes */


"IP_ACTIVE_LOW" is a hacky way to make it always return high, instead of high only when a button is pressed.

iceclmbrj also changes how the service button and coin acceptors work, eliminating the "PORT_IMPULSE" macro. I'm not clear why that would change anything.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 7:37 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 929
Location: New York, NY
Thanks for the suggestions guys, but it still doesn't want to work in my emulator for some reason. I'll keep investigating.

By the way, if the Start bit is always asserted, how do you actually press Start after inserting a coin? Is the bit reversed when the Start button is pressed?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 7:47 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 1023
Yes, Start is Select on Vs., although it's also game-specific. Basically, normal 1P SELECT is "button 1", 2P SELECT is "button 2", 1P START is "button 3", 2P START is "button 4". (I hope I did not get this mixed up.) Most games start two-player mode with "button 2", but a few (Sky Kid and Ninja Jajamaru-kun) want you to use "button 3" for that (and say so on-screen). And then of course is Vs. Tennis, which actually has four different game modes to choose from.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 10:21 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 929
Location: New York, NY
NewRisingSun wrote:
Yes, Start is Select on Vs., although it's also game-specific. Basically, normal 1P SELECT is "button 1", 2P SELECT is "button 2", 1P START is "button 3", 2P START is "button 4". (I hope I did not get this mixed up.) Most games start two-player mode with "button 2", but a few (Sky Kid and Ninja Jajamaru-kun) want you to use "button 3" for that (and say so on-screen). And then of course is Vs. Tennis, which actually has four different game modes to choose from.


I solved it! Everything you guys described is 100% correct. For some idiotic reason, I was ORing $08 with the controller port value as opposed to the button bits that are transmitted through bit-0 of the port. That also explains why $01 appeared to work, while at the same time screwing up the controls. Anyway, thanks again everyone.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 7:11 am 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 75
Figured I'd chime in before the deadline to say I'm in favor of the change to make $00 unspecified, and am OK with whatever ordering for the other devices is most convenient/compatible. While it'd be nice to have standard controllers be $01, I consider it more of a convenience/aesthetic thing than something that's actually important.


As for NES vs Famicom controllers, I have a preference for keeping these separate; having microphone and joypad2 start/select seems to me like a new controller type that does not exist. I don't really see spoilers here as an issue; knowing the game uses the microphone doesn't tell you what it's for, I imagine most players aren't going to notice that the header says to enable the mic, and I thinks spoilers are orthogonal to the purpose of the header, which is to document the needs of the ROM. I also think you could argue that ROM file size could maybe be a spoiler in some cases.

What I'm interested in here is if there are practical problems with choosing one or the other option. Were any games released outside Japan that still check the microphone bit or can be affected by it? Japanese games that respond to both microphone and 2P start/select? Japanese games that use the microphone and encounter glitching if 2P start/select are pressed? If no to all of these, then I guess it's not a big deal, but it does seem weird to me to enumerate all these different controllers yet invent a new emulator-only hybrid for the main controllers. I do think rainwarrior's argument about practicality for emulation is reasonable and strikes me as decent justification reason to keep them separate, but my main concern is definitely compatibility.

Regarding other controllers, I saw mention of desire for a setting to indicate the R.O.B. Stack-Up and I do like it as a signal to the emulator that it should simulate the set, though I understand that it's not at all an input device (rather, the game is the input device for manipulating R.O.B.).


(For the record, having the default expansion device field in the header at all feels weird to me, but I find the argument that it's like the region or console type fields, which I think are important, pretty compelling.)


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 7:31 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21684
Location: NE Indiana, USA (NTSC)
One difference between the region field and the controller field is that the region field directly corresponds to something soldered onto the PCB.* NTSC means no CIC (60-pin cassette) or North America CIC; PAL means PAL A or PAL B CIC.


* With the exception of the handful of 60-pin games that require a PAL famiclone and 72-pin games using a CIC stun circuit.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 7:47 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 929
Location: New York, NY
Fiskbit wrote:
Regarding other controllers, I saw mention of desire for a setting to indicate the R.O.B. Stack-Up and I do like it as a signal to the emulator that it should simulate the set, though I understand that it's not at all an input device (rather, the game is the input device for manipulating R.O.B.).


The default extension device list currently includes "Power Pad Side A" and "Power Pad Side B", as opposed to just "Power Pad". Some other peripherals followed this pattern. R.O.B. deserves separate entries for Gryomite and Stack-Up, respectively.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 9:07 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 1023
Besides the mic being standard rather than expansion and the potential spoiler problem, another practical reason against it having a separate value has come to my mind: how to know whether that value applies to a particular game. For every other device in the list, it is trivial to know whether it applies, at least if you can read Japanese text. But there is no reason to believe that the publicly-available lists of mic-using games are complete. Every Famicom game released before the AV Famicom is a potential candidate for having an obscure or hidden mic-triggered cheat or easter egg. Making that determination for every Famicom game is impossible in finite time. Looking for code patterns will lead to false positives in case of reuse of controller code. Therefore, this field value adds a great deal of uncertainty to the spec, unlike every other value.

As for Stack-Up, I will gladly agree to adding a field value for it once I have been shown what such an emulation would entail or look like. Right now, I cannot quite imagine it.

@tepples: Add to your two exceptions the field value "game detects timing and adjusts itself", which has no soldered-PCB-component counterpart, yet has been a part of the spec since 2006.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 10:13 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7628
Location: Canada
NewRisingSun wrote:
how to know whether that value applies to a particular game. For every other device in the list, it is trivial to know whether it applies, at least if you can read Japanese text. But there is no reason to believe that the publicly-available lists of mic-using games are complete. Every Famicom game released before the AV Famicom is a potential candidate for having an obscure or hidden mic-triggered cheat or easter egg. Making that determination for every Famicom game is impossible in finite time.

That's true for the easter egg cases, we can never be sure to have complete information, but I don't think that uncertainty is a problem in itself? We learn new things, ROMs can be updated, or not. The "standard" field doesn't preclude microphone, so it's an acceptable fallback for "not known to use the microphone", IMO.

However, for the very few cases where the game actually requires microphone to progress, it's a known need. These may be countable on one hand, but that's not unusual for entries in this field.

Quote:
As for Stack-Up, I will gladly agree to adding a field value for it once I have been shown what such an emulation would entail or look like. Right now, I cannot quite imagine it.

Nintaco already has a stack up UI implemented. It's a really good simulation of it!
Attachment:
nintaco_stackup.png
nintaco_stackup.png [ 248.49 KiB | Viewed 8057 times ]


I did have a request for clarification on "SNES Mouse", does that mean in the second controller port, like how thwaite or sliding blaster uses it? Similarly I think Zapper and maybe some other entries should have an explicit port given. (Not looking to add new entries for extra port configurations, just we should be clear about the one that is needed to work. Just a very concise note should be enough.)


Last edited by rainwarrior on Mon Jan 14, 2019 10:48 am, edited 1 time in total.

Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 225 posts ]  Go to page Previous  1 ... 10, 11, 12, 13, 14, 15  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group