It is currently Thu Jul 18, 2019 3:50 am

All times are UTC - 7 hours





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

Joined: Thu May 19, 2005 11:30 am
Posts: 945
rainwarrior wrote:
Nintaco already has a stack up UI implemented. It's a really good simulation of it!
That looks nice in a window. I wonder how to implement that when the emulator is running in full screen mode... but that is of no concern for the expansion device field. Yeah, put Stack Up as value $2E.
rainwarrior wrote:
The "standard" field doesn't preclude microphone, so it's an acceptable fallback for "not known to use the microphone", IMO.
So $01 is "standard, maybe microphone", and $2F (or whatever) then is "definitely microphone"? If I read a standards document like that, I would facepalm at that point.

I kind of forget adding the port for expansion devices because I instinctively think of the RF and Twin Famicom. When there's only one socket, there's nothing to specify. :) I actually know nothing about the SNES mouse and the games that use it, so if you say that it should be in port 2, then port 2 it shall be.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 11:08 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 914
Location: New York, NY
NewRisingSun wrote:
That looks nice in a window. I wonder how to implement that when the emulator is running in full screen mode... but that is of no concern for the expansion device field. Yeah, put Stack Up as value $2E.


Thanks for adding Stack Up support.

With Nintaco, for full-screen mode, I use 2 monitors. In fact, over the past weekend, I played through all 40 levels of Gyromite that way. I was really disappointed that there is no winning scene. It just looped back to "Phase 01".


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

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
NewRisingSun wrote:
rainwarrior wrote:
The "standard" field doesn't preclude microphone, so it's an acceptable fallback for "not known to use the microphone", IMO.
So $01 is "standard, maybe microphone", and $2F (or whatever) then is "definitely microphone"? If I read a standards document like that, I would facepalm at that point.

I don't think that's a silly situation at all.

There's a continuum of: $00 no info > $01 standard controllers > $?? microphone.

The ripper can be as specific as they want about this within that continuum. I'm not calling for there to be a distinction between "easter egg" and "progression blocking", the use of the field that feels practical to me is more like "microphone is worth emulating for this ROM".

The spec can be perfectly clear about what these 3 things mean. Whether to use $?? vs $01 vs $00 is a matter of discretion, the standards or knowledge of the ripper making the header. Am I correct to assume that what you're most opposed to is this discretionary decision, that there might be 3 valid values to put here?


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

Joined: Thu May 19, 2005 11:30 am
Posts: 945
The specification can be semantically clear, I suppose, but the fact that it has "maybes" in it or allows for them, and requires the "maybe" to be changed to a "definite" once somebody has found an easter egg, turns it into a complete joke. Strongly oppose. Imagine somebody who opposes the input device field as a matter of principle, like certain people here, reading something like that in a spec. What an embarrassment. Absolute certainty may be impossible, but if you cannot say with at least 95% certainty what the correct value is, then the specification is mis-specified. Correct specification would be Famicom vs. NES console, which can be said with absolute certainty based on the region in which it was sold.

(Of course, that would be problematic as well with Nintendo games whose ROM content is identical in U.S. and Japanese versions, but that is because the "T.V. System" was so badly specified back in 2006, and one cannot completely redefine it from scratch without invalidating the "huge unknown" of released NES 2.0 homebrew games. I would have specified with four bits --- Japan, North America, Licensed PAL Region, Dendy Region --- with bits set if that particular ROM content was sold in the respective region. That would have taken care of NES/Famicom differences, TV System, controllers, early Nintendo games being sold with identical ROM content everywhere, as well as any detecting-and-self-adjusting games. But it's too late for that.)

Fiskbit wrote:
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?
Japanese games that glitch with 2P START/SELECT? I am not aware of any, and if they exist, they would glitch with the A.V. Famicom as well.

As for North American or PAL games that glitch with the Microphone, I am not aware of any that "glitch" either, though Paperboy will not register button presses while the microphone bit is set, because it compares all bits of $4016 against $41. Note that the microphone bit is never set for an extended period of time but instead oscillates in the presence of a loud signal, as expected by Zelda's microphone code.

I just played the game on my Sharp Twin Famicom, and in practice, using the microphone is not a problem unless I violently blow, constantly, directly into the 2P microphone at very close distance, which then causes the paperboy to waggle around a little while I am pressing left or right. This is not a problem at all with a keyboard/joystick-mapped microphone bit (just don't hit that button!), and in rainwarrior's esoteric situation of an actual microphone, hardware-accurate emulation would require setting the bit's input threshold to such a value that only prolonged loud shouting would trigger it.


Last edited by NewRisingSun on Mon Jan 14, 2019 11:42 am, edited 1 time in total.

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

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21506
Location: NE Indiana, USA (NTSC)
An emulator running on Nintendo DS might emulate the microphone with the actual microphone. Compare Mario Kart DS battle mode, which allows inflating shield balloons while in cover using Select or blowing, but blowing is faster.

_________________
Pin Eight | Twitter | GitHub | Patreon


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 11:59 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
NewRisingSun wrote:
...requires the "maybe" to be changed to a "definite" once somebody has found an easter egg, turns it into a complete joke.

Well, it "allows", not "requires", and I think that's the root of the disagreement. You think someone has to use the field if it's there. I merely think it's a good option to have. There is a difference in intended purpose here which I'm trying to assess.

NewRisingSun wrote:
I just played the game on my Sharp Twin Famicom, and in practice, using the microphone is not a problem unless I violently blow, constantly, directly into the 2P microphone at very close distance, which then causes the paperboy to waggle around a little while I am pressing left or right. This is not a problem at all with a keyboard/joystick-mapped microphone bit (just don't hit that button!), and in rainwarrior's esoteric situation of an actual microphone, hardware-accurate emulation would require setting the bit's input threshold to such a value that only prolonged loud shouting would trigger it.

Unfortunately I don't have a Famicom with a working microphone at this point in time. The times I did try one live, I wouldn't describe the threshold nearly as extreme as you are right now, but I do not have any hard data to offer for comparison. A microphone test ROM that dumps out the bits in a stream would probably be a good thing to have people try on their various machines; I may write one later.

tepples wrote:
An emulator running on Nintendo DS might emulate the microphone with the actual microphone. Compare Mario Kart DS battle mode, which allows inflating shield balloons while in cover using Select or blowing, but blowing is faster.

I said earlier in the thread but Wii U VC actually uses the microphone to emulate the Zelda pols-voice situation. Not sure if there were ever other mic-sensitive games on VC.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 12:05 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
rainwarrior wrote:
You think someone has to use the field if it's there. I merely think it's a good option to have. There is a difference in intended purpose here which I'm trying to assess.
I mentioned before that I want a header specification that defines one correct set of values for each game, every other set of values being incorrect, no ifs or buts. Such a thing is required for the purpose of indexing headered ROM files. That precludes "good options to have", and requires "do this" and "don't do that".

That goal has already somewhat been eroded by the "Unspecified" controller value, but I have grudgingly accepted that as a concession to backwards-compatibility with the understanding that this value is only tentative and not the actual correct value for any given game (except for "allpads", I suppose). But under no circumstance will I accept deliberately defining a field that can be one value but could also be a different value if it pleases the header-editing person one way or the other, with both being equally valid. It must be unambiguous, or it will not be there.

And for the record, NintendulatorNRS for Windows does support the use of an actual microphone, but only when Mapper 515 "Family Noraebang" is active.


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 2:08 pm 
Offline

Joined: Sat Nov 18, 2017 9:15 pm
Posts: 72
I had considered the issue of it being difficult to figure out whether a game uses the microphone when setting headers, but I didn't opt to bring it up because I'm not sure the difficulty of figuring out the right header for a game you know nothing about is all that relevant to whether the values are correct. If a game uses the microphone and the header doesn't indicate it because it was missed, I'd consider that an incorrect header, not the header being ambiguous. I'd feel the same if a game had hidden Zapper support that was initially overlooked.

Similarly, I would expect it to perhaps be difficult to determine that a game is multi-region without looking at the code to see what it does. I could see such a game being marked as one region before it being found it self-adjusts for another, in which case the first header was wrong rather than the header being ambiguous.

Paperboy sounds like something that should very explicitly not have microphone support. While most emulators today don't use an actual mic, I don't think we should assume it won't be more common in the future.

@NewRisingSun: Can you shed more light on what cases you consider to be ambiguous? If there is one correct option, but it is difficult to determine which that is, is it ambiguous? And at what point is a game determined to be using an input option? For example, if a game has code to read Zapper input and does actually read it, but never uses it (maybe Zapper support was abandoned during development) or maybe only uses it in inaccessible content, is it a Zapper game if there's no other use for port 2?


Top
 Profile  
 
PostPosted: Mon Jan 14, 2019 2:22 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
Well, it's not ambiguous if you define $01 as "Standard controllers, no microphone". It is ambiguous if you define (as I understand rainwarrior, at least) $01 as "Standard controllers, microphone optional", $2F as "Standard Famicom controllers, microphone required" for games like Zelda, and leave it optional to change any game that once was a suspected mic candidate and later has been discovered to support the mic for an easter egg to $2F.
Fiskbit wrote:
While most emulators today don't use an actual mic, I don't think we should assume it won't be more common in the future.
My little self-test anecdote was supposed to show that even with an actual mic, the game is pretty robust against mic bit interference unless you go out of your way to cause the problem.
Fiskbit wrote:
I could see such a game being marked as one region before it being found it self-adjusts for another, in which case the first header was wrong rather than the header being ambiguous.
I have never seen, and would indeed find it hard to imagine, a self-adjusting game where the adjustment was not immediately obvious either in music speed, music pitch, or (lack of) split screen glitches. Since most emulators allow you to change the region without resetting, you can always compare how the game behaves with the region changed mid-game versus with the selected region being active at reset when the game performs the detection.
Fiskbit wrote:
If a game uses the microphone and the header doesn't indicate it because it was missed, I'd consider that an incorrect header, not the header being ambiguous. I'd feel the same if a game had hidden Zapper support that was initially overlooked.
Right, we are discussing two different issues --- the ambiguity issue exists only with rainwarrior's "good option to have" variant. The more conventional variant, $01 if the game ignores or is even bothered by the mic and $2F if it reads the microphone and does something with that at some point, only presents the difficulty of finding out which one of the two cases it is.

Since my last post, I have written up a little program (attached) that just scans the PRG-ROM of a wildcard of command-line-specified .NES ROM images for common variants of the "LDA/LDX/LDY $4016" followed an "AND $04" instruction in the 32 bytes afterwards. I get about 50 candidates when running it over the entirety of licensed Japanese Famicom cartridge games, including all the known ones, but then some. The .log file, also included, shows the names as well as the PRG-ROM offsets where the read candidate was found.


Attachments:
hvcmic.7z [23.75 KiB]
Downloaded 210 times
Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 3:20 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
I have taken very rough look at most of the games that hvcmic identified as mic-using candidates. "Code exists and is definitely called" means that I can set a breakpoint at the code that reads and checks the microphone bit, and will eventually find it triggered. Usually, that sets a memory location; whether the game does anything with that, or just calls that code as part of an input device library is another question. "Code exists, but unreached in tests so far" means that the code is definitely a mic-reading and checking code, but my brief encounter with that game has not reached a point where that code was ever called. It may be called at some point in the game, or it maybe unreachable code as part of an input device library. "False alert" means that it's obvious that it cannot be mic-reading code. "Undetermined" means that I have not yet taken a closer look.

If we can create a perfect list based on analyzing this rather limited list of games, then we can add a field value for Mic. I will not do such an analysis all alone on my own, however.


Attachments:
hvcmic-filtered.txt [2.21 KiB]
Downloaded 210 times
Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 3:33 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8484
Location: Seattle
Is there any reason to think that programs may have instead done "LDA #4 / BIT $4016" ?


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 3:36 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
Seems unusual, but I can check.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 3:42 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 945
No licensed Japanese ROM has A9 04 2C 16 40.


Top
 Profile  
 
PostPosted: Tue Jan 15, 2019 4:20 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7528
Location: Canada
To be clear, my goal wasn't to force you to use it in your ROMset releases, or to force some hunt for the "complete list" to be concluded before adding it. I know you don't like things that are optional, but if the fear is that you might release a set that you later feel you have to update because of this field, that's not my intent at all. If you really want your ROMset to be 100% consistent forever, I don't think you should want to even attempt to use a mic value in this field ever, but I think that goal is too absolute to be possible. We'll never know for sure which games definitively ignore it. This is more or less an "impossible to prove a negative" situation.

The oft stated purpose of iNES 2.0 was to make it so emulators "don't have to use CRCs" to decide what to do with a ROM. The peripherals thing was a big existing case where a lot of emulators were doing just that.

So to me, use of the microphone is a potential for that, something an emulator might otherwise have to use CRCs and internal database to accomodate.

It is only proposed as an option, to provide more information for those who would want it, in cases where there is a known use for it. I would absolutely not propose it as something that must be used in every case where it is known. That's standards guideline for a ripper to apply to their own sets of ROMs, not something that belongs in a specification for what this field means.


I'm happy that research might be done on microphone games. It's an interesting topic. I intend to contribute at least a test ROM to that research myself, but if you're proposing a big (volunteer) investigation like this needs to be done just for the sake of this field...? No, that's not something I'm demanding. This is a soft proposal for future inclusion, if others want it. A thing that we can add later to disambiguate the games a little more, when we know a little more. Backward compatibility and continuity are important here, headers can be refined with new knowledge as it becomes available, and if that is kept in mind we don't have to create any new situations that invalidate prior work.


So... I don't even want to propose this if this is what you're going to take it to mean. I don't vote for it to mean that. I'd rather drop my support for a mic value.


Top
 Profile  
 
PostPosted: Wed Jan 16, 2019 11:46 am 
Offline

Joined: Tue Nov 23, 2004 9:35 pm
Posts: 740
NewRisingSun wrote:
I have taken very rough look at most of the games that hvcmic identified as mic-using candidates. "Code exists and is definitely called" means that I can set a breakpoint at the code that reads and checks the microphone bit, and will eventually find it triggered. Usually, that sets a memory location; whether the game does anything with that, or just calls that code as part of an input device library is another question. "Code exists, but unreached in tests so far" means that the code is definitely a mic-reading and checking code, but my brief encounter with that game has not reached a point where that code was ever called. It may be called at some point in the game, or it maybe unreachable code as part of an input device library. "False alert" means that it's obvious that it cannot be mic-reading code. "Undetermined" means that I have not yet taken a closer look.

If we can create a perfect list based on analyzing this rather limited list of games, then we can add a field value for Mic. I will not do such an analysis all alone on my own, however.


Interesting list. There are a two games which my sources inform me do support the Famicom microphone which aren't on that list :
快傑ヤンチャ丸 - Kaiketsu Yanchamaru
スーパーチャイニーズ2 ドラゴンキッド - Super Chinese 2: Dragon Kid

Of course, almost every licensed Famicom game could theoretically support the Microphone because all official Famicoms released until the release of the AV Famicom on December 1, 1993 had or could have (Sharp C-1 TV) a microphone in the second controller. Actually, Cartridge Famicom Zelda 1 was released in 1994, so I don't think you can limit it to the AV Famicom's release. I think that if anyone is likely to play the games that must have a microphone, (as opposed to an Easter Egg/Cheat-like use as with Zelda) they'll probably know to set their emulator for a Famicom or use the game in a non-AV Famicom.

I might suggest limiting the Microphone choice to games that are known to absolutely require it. As far as I know, those games are :

爆笑!!人生劇場 - Bakushou!! Jinsei Gekijou
爆笑!!人生劇場2- Bakushou!! Jinsei Gekijou 2
スーパーチャイニーズ2 ドラゴンキッド - Super Chinese 2: Dragon Kid
たけしの挑戦状 - Takeshi no Chousenjou (a workaround may exist involving Down + A on Controller II)

_________________
Nerdly Pleasures - My Vintage Video Game & Computing Blog


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 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