It is currently Sun Jun 16, 2019 2:13 pm

All times are UTC - 7 hours





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

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
OK, I stand corrected that most of its uses were cheats and easter eggs. I was going by memory of the mic games I had tried in emulator. I still feel the same way regardless.

As far as emulators that support a real mic, the one I have seen so far is the Wii U VC. Otherwise I've seen talk about it from time to time, but no I don't know of any current free emulators that do it. It's something I'd like to see, and I think having the mic spec in byte 15 would help.

Unless you have an always on microphone attached to your PC and listening, though, there is NO mechanism to discover these naturally in an emulator. Nobody is naturally ever pressing some extra useless "mic" button all the time; if you are doing that, you are looking for something specific you already know about. You're complaining about a "spoiler" for a thing that can't actually be found without one.

So... to me the spoiler part is quite unimportant, for that reason, but the need for the emulator to have a heads up about the mic is practical, because a hardware device shouldn't be open unless it's needed. That's an implementation problem for the emulator author, but I think this field helps.

If the spoiler is the issue here, the emulator can refrain from broadcasting noticing that bit to the user, if possible. That's a UI issue, not a header spec issue. Complaining that someone who is inspecting iNES headers is getting spoilers from them seems like an unimportant case to me.

NewRisingSun wrote:
rainwarrior wrote:
Are you trying to argue for its removal just to free up $01 to stick standard controller spec into?

Is that not what I wrote?

So, putting the issue of whether microphone should be included at all aside, does that mean you'd be in acceptance with:

$00 no information
$01 standard controllers
the rest as before, and we can take consensus on whether microphone needs an entry and add it to the end, or not, at a later time


Last edited by rainwarrior on Sat Jan 12, 2019 1:59 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 1:59 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
I would grudgingly accept defining $00 as "Unspecified" if no particular emulator behavior is assumed from that, and redefining $01 as "Standard NES/Famicom Controllers".
rainwarrior wrote:
Nobody is naturally ever pressing some extra useless "mic" button all the time
It is no more absurd to press "M" all the time than it is to yell into an actual RF Famicom's 2P controller all the time. Real hardware players can do the latter, so emulator players should be able to do the former. "A header is not an encyclopedia about the game." Therefore, the header has to be silent about game cheats, puzzles and easter eggs.
rainwarrior wrote:
so I can't possibly know what you have prepared looks like
You could possibly know with a simple Google search for "Project Plug 'n Play".


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 2:09 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
NewRisingSun wrote:
rainwarrior wrote:
so I can't possibly know what you have prepared looks like
You could possibly know with a simple Google search for "Project Plug and Play".

I did actually google it when you mentioned it, but that thread isn't in the results: 1 2 3, though regional results may vary.

The question being asked of that is "What mess has been created, and what help are you asking for to fix it?" Now that you've pointed me to the ROMset you made, what mess do you want me to see in it? What help do you want?

How many of these use values other than $00 in that field? Yes technically I could sift through 25MB of recursive .7z files to find it, but I thought you might have that information available quickly/easily.

Is this all the ROMs that you know of that use that field?


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

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
And BTW I'm very glad that you've made the effort to design this field, and create ROMsets. Please stop treating me like I am hostile to it. I had one issue with it, and apparently you changed your mind about the microphone which I thought was good, but I don't think this warrants the attitude you seem to be presuming from me.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 2:16 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
I want(ed) you to propose a solution that considers all needs, not always find reasons for everything I propose of why that is not okay either. You also may have noticed that I react very badly when people bother to take the time to express their indifference. I would say if somebody does not care, then why does he not just shut up? I mean this as a general statement.

I have signalled a willingness to compromise in my last post. If it pleases you to find that one acceptable, then make it official in the spec. As I said previously, I will no longer touch that part of the spec.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 2:38 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
No, Header byte $F is not "tentatively proposed". The only thing that is "tentative" is whether the Mic gets its own value or not. I am not going to update my ROM sets for a "tentative" proposal.


Last edited by NewRisingSun on Sat Jan 12, 2019 2:42 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 2:39 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
Okay, I'm not sure that I meant "indifferent" in the same sense you took it, but I will avoid using that word in that way in the future. In most cases I was looking for a way to say that several options are acceptable, and "indifferent" seemed like a suitable word.

As far as the microphone, no I do care about that one, I think it should be included. What I was indifferent to thought was variably acceptable was whether the existing numbers were rearranged... but I thought you might have an opinion on rearranging the numbers, and you did, which is exactly "the part of disavow I don't understand"; I wanted you to speak on it.

I have restored the description of the field here with the compromise:
http://wiki.nesdev.com/w/index.php/NES_2.0#Default_Expansion_Device

A straw poll / comments from others would always be helpful. Do people like this field? (I do. NewRisingSun and Lidnariq appear to be in favour of it. Bregalad against.)

Does anyone besides me feel that mic should be included?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 2:43 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
NewRisingSun wrote:
No, Header byte $F is not "tentatively proposed". The only thing that is "tentative" is whether the Mic gets its own value or not.

For anyone else observing, that was in reference to words I added to the restored description on the wiki between my last two posts.

I called it tentative because others have had no time to comment on this version of the specification yet.


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

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 913
Location: New York, NY
NewRisingSun wrote:
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.


Thanks. That got Tetris going.

Vs. Gumshoe (set GM5) is 48 KiB. Do I have to treat it like [8 KiB padding] + [24 KiB first half] + [8 KiB padding] + [24 KiB second half] ? That is, when you created the padded version of the file, did you stick the padding in those places?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 2:57 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
Code:
copy /b ..\vsgshoe.hdr +mds-gm5.1d +mds-gm5.1c +mds-gm5.1b +mds-gm5.1a +mds-gm5.2b +mds-gm5.2a "..\out\Vs. Gumshoe (set GM5).nes"
copy /b ..\vsgshoe_pad.hdr +mds-gm5.1d +mds-gm5.1c +mds-gm5.1b +mds-gm5.1a +pad.8k +mds-gm5.2b +mds-gm5.2a "..\out\Vs. Gumshoe (set GM5)(padded).nes"
Edit: The 8k padding in Gumshoe goes after the first 32k40k (because mds-gm5.1d is 16k), meaning at the end of PRG-ROM. The padding had to be done because before the multiplicator/exponent notation was added to NES 2.0, it was not possible to specify 40k.

The spec defines Vs. Gumshoe as a unique case, only following the fact that its mapper is a unique case of mapper 99: all other mapper 99 games only switch CHR-ROM, but Gumshoe also switches PRG-ROM at $8000-$9FFF. (And I would like to point out that the weird way of arranging the (padded) Gumshoe ROM long predates NES 2.0, so it's not something that I cooked up.)
rainwarrior wrote:
Do people like this field? (I do. NewRisingSun and Lidnariq appear to be in favour of it. Bregalad against.
No, I don't want to re-open the discussion on whether to have this field at all. We have had the past six months to do that, and I have already seen the quality of the responses on the "no" side. Comment on values $00/$01 and whether to have a Mic entry or not, but not whether the header should specify a default input device in general.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 3:48 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 668
Like NewRisingSun said, this field was proposed a long time ago, and people have had a very long time (9 months!) to give their opinion on it, I don't think there's any reason to reopen that particular debate.

As for making $00 "unspecified" and $01 "standard controllers" while keeping everything else intact, that's fine by me, seems like the most sensible way to fix the current issue without breaking too many potential things.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 3:58 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 913
Location: New York, NY
NewRisingSun wrote:
Code:
copy /b ..\vsgshoe.hdr +mds-gm5.1d +mds-gm5.1c +mds-gm5.1b +mds-gm5.1a +mds-gm5.2b +mds-gm5.2a "..\out\Vs. Gumshoe (set GM5).nes"
copy /b ..\vsgshoe_pad.hdr +mds-gm5.1d +mds-gm5.1c +mds-gm5.1b +mds-gm5.1a +pad.8k +mds-gm5.2b +mds-gm5.2a "..\out\Vs. Gumshoe (set GM5)(padded).nes"
Edit: The 8k padding in Gumshoe goes after the first 32k40k (because mds-gm5.1d is 16k), meaning at the end of PRG-ROM. The padding had to be done because before the multiplicator/exponent notation was added to NES 2.0, it was not possible to specify 40k.

The spec defines Vs. Gumshoe as a unique case, only following the fact that its mapper is a unique case of mapper 99: all other mapper 99 games only switch CHR-ROM, but Gumshoe also switches PRG-ROM at $8000-$9FFF. (And I would like to point out that the weird way of arranging the (padded) Gumshoe ROM long predates NES 2.0, so it's not something that I cooked up.)


Thanks.

The only VS UniSystem game that I can't run at the moment is Vs. Ice Climber (set IC4-4 B-1). However, Vs. Ice Climber (set IC4-4 X) works just fine. Does the former have some sort of hardware protection?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 4:03 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 928
Yes, as denoted by the high nibble of byte $D having value $4: Vs. Unisystem (Vs. Ice Climber Japan protection). The protection involves one of the buttons (bit value 0x08) being permanently pressed; I think that's START or SELECT, but I am not sure which. (I need to add that to the wiki.)
Sour wrote:
As for making $00 "unspecified" and $01 "standard controllers" while keeping everything else intact, that's fine by me, seems like the most sensible way to fix the current issue without breaking too many potential things.
Ok. 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?


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 4:48 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 913
Location: New York, NY
NewRisingSun wrote:
Yes, as denoted by the high nibble of byte $D having value $4: Vs. Unisystem (Vs. Ice Climber Japan protection). The protection involves one of the buttons (bit value 0x08) being permanently pressed; I think that's START or SELECT, but I am not sure which. (I need to add that to the wiki.)


That didn't seem to work. I tried all 8 possibilities and none of them did the job.


Top
 Profile  
 
PostPosted: Sat Jan 12, 2019 4:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7499
Location: Canada
NewRisingSun wrote:
Comment on values $00/$01 and whether to have a Mic entry or not, but not whether the header should specify a default input device in general.

Yes $00 and $01 is the tentative part. Though you said yourself you were disappointed in the lack of commentary on the rest. If there's anything else that needs to be said, now is A GOOD TIME for that.

And some will always disagree, they should still get to say that.

NewRisingSun wrote:
I am not going to update my ROM sets for a "tentative" proposal.

Well, you really shouldn't, and neither should anyone else, at this very moment. I put that word in because it's simply too early for anyone who casually finds this thing we discussed in the last few minutes on the wiki to take it as something they can rely on.

Please stop trying to stick a knife into everything I say. It's a solution we agree on, right? Good. 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!


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

All times are UTC - 7 hours


Who is online

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