It is currently Tue Sep 25, 2018 7:39 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Thu Apr 05, 2018 10:51 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6827
Location: Canada
lidnariq wrote:
There's plenty of homebrew that supports a choice of multiple different controllers via any given input; are there commercial games that do so also?

Operation Wolf and Bayou Billy both have Zapper and Zapper-Free options, I think.

Is there much need to try and account for multiple possible input configurations? I feel like this field is more about specifying a useful input set where the standard option doesn't work. If it's a multiple choice thing, probably specifying the most standard (subjective, I know) option is fine?


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 10:53 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
No, because when you connect the Zapper, Bayou Billy and Operation Wolf still allow you to use the controller, so an emulator can plug in the Zapper just in case without restricting the user's choices. I have rephrased Note 1 in the Input Device proposal accordingly. The only difficulty that will remain is when several options conflict by using the same controller data bus fields and so cannot be connected simultaneously.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 1:39 pm 
Offline
User avatar

Joined: Thu Jan 03, 2008 1:48 pm
Posts: 568
tepples wrote:
Just a wild guess, but Nintendo's factory probably tested 2A03 CPUs received from Ricoh, and the test rig had a 2A03 socket and some additional MMIO port that controls the test mode pin, letting the program switch between test mode and run mode. But I imagine that sort of stuff would be even more obscure than the Nintendo PlayStation. So until such a test rig surfaces, I oppose baking into NES 2.0 a means to distribute a firmware for it.

I'm not entirely certain the logic of why something that is inherently in the 2a03G and exists would not be added into NES 2.0 specs; as opposed to Famiclones that are based on the hardware but may have different PPUs or palettes. Vs. and Dual units are available as well. It's apparent that the NES 2.0 format's purpose is to include as many multicarts, Famiclones, arcade hardware, peripherals, and features of the NES as possible; making it as future-proof as it can be; including additions of homebrew mappers and peripherals.

If someone really wanted to, there shouldn't be any way to stop them from creating a visualizer demo for the triangle register, etc. and something to make it easier for the emulator to know that TEST mode needs to be enabled.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 2:36 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
But no such Visualizer exists yet. You are asking for an entry for a hypothetical ROM that may or may not ever be created. Let somebody make such a Visualizer, and then we'll see.


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 4:32 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6827
Location: Canada
By the way, I am very much in favour of the input enumeration field. I actually suggested the same thing 4 years ago but nobody in that thread seemed to like the idea. I think it would be very nice if emulators had a way of knowing which devices to use.

There as another relevant thread about a year ago wondering about how to include extra data besides PRG/CHR.

There was another suggestion I had that the new byte 9 as "upper bits of ROM size" was ill conceived, as there are already ROMs in the wild bigger than it fits (e.g. 1 bit shy of "A Winner is You" 64MB PRG). You could use the same 4 bits as an power of 2 exponent instead of as an extended binary number and we'd always have big enough size. However, I don't know to what extent these bits are already in use, so I am not sure how appropriate it would be to consider revising it at this point. (Edit: found the previous discussion which was also asking about the utility of values like 0 or 255 in the iNES1 PRG size field.)


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 4:52 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
3gengames' objection is strongly-worded but unpersuasive. In any case, there are still some open questions in the input device field's thread, in particular whether it should include the expansion port storage devices or not.

The largest ROM image in the wild is 128 MiB, but there is no reason that it will stay that way. How about if byte 9 is FF, then the PRG-ROM size is 64 SHL byte 4 and CHR-ROM size is 64 SHL byte 5. (Byte 9 being FF would otherwise denote 62,914,560 to 67,092,480 bytes of PRG-ROM plus 31,457,280 to 33,546,240 bytes of CHR-ROM, both slightly less than 64 and 32 MiB, a value so unlikely that it can safely be used for a special meaning.) A maximum size of 64 SHL 255 should hold a while. (And it will finally at last allow for a non-overdumped Galaxian! :lol: (ducks away))


Last edited by NewRisingSun on Thu Apr 05, 2018 5:04 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 5:00 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6827
Location: Canada
I kinda like that use instead of 2^15. Heaven help us when we finally reach the 64GB homebrew though. ;)

Though we could even bias the exponent something like +4 or +6 and trade away some not-very-necessary non-power-of-two precision for even bigger sizes. +5 would get us to 1TB.

Oh, as far as the "test pin" thing, I think the thought of it being a potential input enumeration is kind of convenient. You might think of lifting and rewiring that pin as a similar "input device" situation as expansion ports. The convenient part though is since the enumeration is a living and open spec, easy to add to as cases come up, allocating that enumeration can certainly wait for a real ROM to use it with. Kinda meets both needs at once (i.e. "I want the spec to be able to support this" and also "I don't want to waste spec on something that has no use case".)


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 5:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7554
Location: Seattle
NewRisingSun wrote:
The largest ROM image in the wild is 128 MiB, but there is no reason that it will stay that way.
I think there's actually a fairly firm limit at 256 MiB—that's the size of the largest NOR flash available. (and that's both BGA only and also more expensive than two 128 MiB ROMs)

I'm a little worried about not supporting multiple ROMs of dissimilar size without explicitly encoding mirroring in the dump.

(I'm also pretty certain that there are no market forces suggesting we will ever see silicon dice holding even more bytes)


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 7:23 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6827
Location: Canada
Actually the "64 shift" though made me think a little more minimally: if a nonzero value in the oversize ROM nybble just specified that the original byte 4/5 is now an exponent, the range now easily extends from 1 byte to eternity. Could even use the 15 values to specify an odd multiplier to accomodate 14 different varieties of non-power-of-two sizes.

0 -> (original 16k * N)
1-15 -> 2^N * [1,3,5,7,9,11,13,15,17...]

Kind of turns the original byte into a "chip address size" and the oversize nybble into a "chip count".


(I'm just golfing here, though. I'm not personally very interested in gigantic ROMs. The existing size spec is plenty good enough for everything I selfishly care about.)


Top
 Profile  
 
PostPosted: Thu Apr 05, 2018 11:23 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6827
Location: Canada
Actually... maybe you could even keep it compatible with the current spec. With things as they are, the oversized nybble $F is practically useless anyway, so you could treat that value as a new special value to mean the original byte is reinterpreted exponentially/floating-pointish.

For example, you could use 2 bits for multiplier, and 6 bits for exponent you'd have 2^[0-63] x [1,3,5,7]

...or 3 and 5 would still get you to 2GB... or you could bias the exponent by +10 and only have 1k granularity but go up to 2TB.

Really there's tons of expressive room just in the original byte this way. (Sorry for rambling on about something I don't actually think will ever be useful, ha ha. Just the more I thought about it, the more it seemed like bits were being wasted here.)


Top
 Profile  
 
PostPosted: Wed Jul 04, 2018 12:13 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7554
Location: Seattle
Per MAME and Nocash, we know of six (seven) total games that use the Vs. System's ability to communicate between the two CPUs:
* Balloon Fight ("balonfgt")
* Baseball ("vsbball", "vsbballj", "vsbballja", "vsbballjb")
* Ice Climber ("iceclmrd")
* Mahjong ("vsmahjng")
* Tennis ("vstennis", "vstennisa", "vstennisb")
* Wrecking Crew ("wrecking")
** (Raid on Bungeling Bay ("bnglngby"))

All of these run directly on the MDS mainboard without extra bankswitching hardware; they're all technically mapper 99. Of these, five are 32K PRG and 16K CHR on each side. Mahjong has 24K PRG and 8K CHR; Raid on Bungeling Bay has 8+32K PRG and 0+16K CHR.

Earlier in this thread, NewRisingSun suggested packing both CPU's PRG and both PPU's CHR into a single file.

This is not quite entirely unambiguous. I am uncomfortable with defining 16K CHR to mean two different things depending on the size of PRG. Additionally, this naive concatenation rule runs into problems between Raid on Bungeling Bay (0+16) and Vs. Mahjong (8+8). Since defining either of these as the "correct" definition only allows a single game to be emulated, and requires that the other be padded up to 32K CHR in the file, I'm inclined to say that both should require padding CHR, and the 64K PRG+16K CHR configuration shouldn't be allowed in a mapper 99 DualSystem image.

(Vs. Mahjong does not use the CHR bankswitching ability, but it is directly on the MDS mainboard and so is technically mapper 99, not mapper 0. Additionally, I'd like to keep this logic all confined to mapper 99, if practical, rather than defining an alternative behavior in another mapper to handle a single game.)

I'm also a little uncomfortable with having something that looks like an ordinary NES file but suddenly pops up two screens and requires four controllers, but whatever.

As a final worry, mapper 185 was explicitly defined because people didn't like baked-in padding in the corresponding NES images. (All of the games would run if dumped and emulated as 32K CHR CNROM). So defining padding into the encapsulation—at least for the instances where the padding isn't an artifact of the limited precision of the ROM size fields in the header—is directly contrary to the goals that lead to the definition of mapper 185.

Does anyone else have any thoughts on this matter?


Top
 Profile  
 
PostPosted: Wed Jul 04, 2018 12:56 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
lidnariq wrote:
I am uncomfortable with defining 16K CHR to mean two different things depending on the size of PRG.
You are not defining 16 KiB CHR to mean two different things depending on the size of PRG. You are defining 16 KiB CHR to mean two different things depending the console type field.

As for padding, I see it less like Mapper 185 and more like padding Galaxian from 8 KiB to 16 KiB PRG.

lidnariq wrote:
I'm also a little uncomfortable with having something that looks like an ordinary NES file but suddenly pops up two screens and requires four controllers, but whatever.
I have already implemented Vs. Dual support in Nintendulator-NRS, and added the ability to only view one of the screens. The four controllers are reused from the user's NES Four Score configuration. The only thing left to add is mirroring of the P3 and P4 controls when using a single screen only. This has to be game-specific --- Vs. Tennis must invert both horizontal and vertical controls, Vs. Wrecking Crew only the horizontal ones, and Vs. Balloon Fight none.

lidnariq wrote:
Additionally, this naive concatenation rule runs into problems between Raid on Bungeling Bay (0+16) and Vs. Mahjong (8+8). Since defining either of these as the "correct" definition only allows a single game to be emulated, and requires that the other be padded up to 32K CHR in the file, I'm inclined to say that both should require padding CHR, and the 64K PRG+16K CHR configuration shouldn't be allowed in a mapper 99 DualSystem image.
Since both Vs. Mahjong units' CHR-ROMs are identical, you only need to include 1x8 KiB, and let the emulator's mapper interface with its address wrapping capabilities do the rest. Both games run fine here without any hitch, so the problem you are describing seems to be entirely theoretical.


Top
 Profile  
 
PostPosted: Wed Jul 04, 2018 1:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7554
Location: Seattle
NewRisingSun wrote:
You are not defining 16 KiB CHR to mean two different things depending on the size of PRG. You are defining 16 KiB CHR to mean two different things depending the console type field.
NewRisingSun wrote:
Meaning of Byte 13 if byte 7 bits 0-1==1: Vs. System palette and extra information:
Code:
Bits 0-3: Palette (unchanged from current spec)
Bits 4-7: Vs. Mode
[...]        0 - Normal- no special mode(s)
        7 - Vs. Dual System with normal inputs
        8 - Vs. Dual System with reversed inputs
        9 - Vs. Raid on Bungeling Bay (dual CPU, protection: controller bit $08s always 1, also reversed inputs)
Ah, ok. 16KB CHR in Vs.Mode==0,9 is single PPU with 16 KiB CHR, 16 KiB CHR in Vs.Mode==7,8 is two PPUs with 8 KiB CHR each. 32 KiB CHR is only defined for Vs.Mode==7,8.

Quote:
As for padding, I see it less like Mapper 185 and more like padding Galaxian from 8 KiB to 16 KiB PRG.
Well, the CHR padding concerns were due to not remembering the extra Vs. System modes.

I guess I'm still a little uneasy with adding 24 KiB of padding to Raid on Bungeling Bay, which does feel much more like mapper 185 than Galaxian to me.


Top
 Profile  
 
PostPosted: Wed Jul 04, 2018 1:15 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 517
Thanks for taking the time to post this!

I'm essentially done adding support for VS DualSystem, I just need to finalize the exact way Mesen expects the roms to be stored at this point. Personally I don't have any strong opinions on the subject - I just want to avoid creating 2 different implementations for the same thing.

Is everything in this thread still just a "proposal"? If everybody is ok with the proposals, I'm happy to implement them on my end.

lidnariq wrote:
I guess I'm still a little uneasy with adding 24 KiB of padding to Raid on Bungeling Bay, which does feel much more like mapper 185 than Galaxian to me.
Considering the game-specific header setting, the padding could be limited to just 8kb, I think? (and only because the iNES header enforces multiples of 16kb)


Top
 Profile  
 
PostPosted: Wed Jul 04, 2018 1:41 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 655
I was about to post updates to the proposals (this thread and the input device one) based on my experiences in implementing them in Nintendulator-NRS, sometime next week.

I would still like to solicit more input on how to deal with ROMs with more than 64 MiB of PRG-ROM.

Edit: We could use a completely unpadded Vs. Mahjong (banks A,C,E unit 1, banks A,C,E unit 2, yielding 48 KIB of PRG) and an Vs. Raid on Bungeling Bay padded only to 48 KiB. Here's what my mapper 99 bankswitching code would look like:
Code:
void   Sync (void) {
   EMU->SetPRG_RAM8(0x6, 0);
   EMU->SetPRG_ROM32(0x8, 0);
   EMU->SetCHR_ROM8(0, CHR[0]);
   // Vs. Gumshoe has an extra 8KB of PRG ROM which it swaps using the same register
   if (ROM->INES_PRGSize ==3) EMU->SetPRG_ROM8(0x8, CHR[0] << 2);
   
   if (ROM->INES2_VSFlags ==VS_DUAL || ROM->INES2_VSFlags ==VS_BUNGELING) {
      if (ROM->INES_PRGSize ==3) { // 48 KiB of PRG-ROM means trimmed ROM
         if (ROM->INES2_VSFlags ==VS_DUAL) { // Vs. Mahjong
            EMU->SetPRG_OB4(0x8);
            EMU->SetPRG_ROM8(0xA, 0);
            EMU->SetPRG_ROM8(0xC, 1);
            EMU->SetPRG_ROM8(0xE, 2);
            EMU->SetPRG_OB4(0x18);
            EMU->SetPRG_ROM8(0x1A, 3);
            EMU->SetPRG_ROM8(0x1C, 4);
            EMU->SetPRG_ROM8(0x1E, 5);
         } else { // Vs. Raid on Bungeling Bay
            EMU->SetPRG_ROM32(0x8, 0);
            EMU->SetPRG_OB4(0x18);
            EMU->SetPRG_OB4(0x1A);
            EMU->SetPRG_OB4(0x1C);
            EMU->SetPRG_ROM8(0x1E, 5);
         }
      } else {
         EMU->SetPRG_ROM32(0x8, 0);
         EMU->SetPRG_ROM32(0x18, 1);
      }
      EMU->SetPRG_RAM8(0x16, 0);
      EMU->SetCHR_ROM8(0x10, CHR[1] |2);
   }
}
Without such trimming, the "if (ROM->INES_PRGSize ==3)" block would be gone, yielding a much more streamlined implementation. Note: Bank 0x18 means CPU bank starting at $8000 of the second unit. OB4 means Open Bus. The trimming would also be kind of awkward for Vs. Mahjong because one of the 16 KiB banks would contain PRG data from both units.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 65 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

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