I would like to propose additions to the NES 2.0 format for your esteemed consideration. Reasons:
- I have counted at least ten games now that require Dendy timing and are incompatible with RP2C02 and RP2C07 timing. "Incompatible" in one case means the game (西天取经 II - Journey to the West) crashes at the beginning of a boss battle.
- Several mutually-incompatible Famiclones need to be distinguished from each other.
- The Vs. Dual System is not supported.
- Additional protection types on the Vs. Unisystem need to be specified.
Edit: Updated version
here.
By request, reposting my brief summary of what dendy is, originally posted here:
http://tasvideos.org/forum/viewtopic.ph ... 169#467169Here is a
map of countries and video signal standards used in them. Note how huge the PAL/SECAM zone is. Compare it to which countries the NES/Famicom console was sold in.
en.wikipedia.org/wiki/History_of_the_Nintendo_Entertainment_System#Going_international_(1984-1987)
You will notice that most of the world has never seen official NES/Famicom release. That led to pirated clones of this console being sold all over Eurasia in early 90's.
A Taiwanese hardware manufacturer,
TXC Corporation, developed a device compatible with Famicom and with PAL/SECAM signal at the same time. They called it
Micro Genius, and it was sold under different names all over Eurasia, where no PAL NES or Famicom was sold.
In Russia it was sold as Dendy, and by that name it was
recognized by the emulation scene, because it was Russian enthusiasts
(one of them you can see right above this post) who studied how Dendy operates and how it differs from official consoles, and they convinced several emulator authors to add Dendy mode, in addition to NTSC and PAL. In most emulators it's called Dendy mode, but in fact it was a Hybrid mode technically speaking: NTSC games working on a PAL console, and Dendy wasn't the console this mode originated from, Micro Genius was.
Most of the time pirates were simply ripping off NES and Famicom games, occasionally adding cheats to them, sometimes breaking them by this. Some games were developed for PAL Famiclones from scratch, but it's not easy to find them (TXC themselves
developed some of them). And finally, there were ports of other consoles games to this platform.
One of the developer teams doing such ports was
Hummer Team. There is a HUGE article about its history, in Russian, called
Hummer Team: все, что вы хотели знать о главных пиратах.
Right now I have no info on whether such bootleg games were sold outside Micro Genius area. Since they were perfectly compatible with Famicom, there is a high chance they were sold in Japan. But carts such games were released on are incompatible with NES, and PAL NES timings were incompatible with those of Micro Genius. Considering that even official PAL NES wasn't very popular in Europe, bootleg games had vanishingly little chance to ever exist on the PAL NES market.
This leaves us with a conclusion that bootleg games made by Asian developers for Micro Genius market were basically only spread within that market, with little possible exception of appearing in official NES/Famicom area.
Eugene.S wrote:
viewtopic.php?f=3&t=2090&start=75#p180674
Specifying what is "preferred" is somewhat subjective. I would rather specify what a game
needs.
And if an emulator author can be bothered to support the expanded NES 2.0 field, they can also be bothered to make the simple changes needed for "Dendy"-like timing, so additional values for emulators that only support the expanded field but not "Dendy"-like timing seem wasteful.
feos wrote:
By request, reposting my brief summary of what dendy is, originally posted here:
I will gladly rename "Dendy timing" to something else if you prefer. What I mean is a 50 Hz PPU with 312 scanlines that starts the NMI at scanline 291. Games that "need" Dendy timing use screen splits timed according to an 21-scanlines-long NMI period, but have an NMI handler that sometimes takes more than 262 lines and thus will freeze on a regular NTSC console because the next NMI is raised when the previous has not finished yet, for example when massaging level data.
Thank you feos. I've added the info about "Micro Genius by TXC" being the original name to
the wiki's article about regional console subtypes.
NTSC Famiclones:Code:
UMC UA6527 (CPU)
UMC UA6528 (PPU)
TA-03N (CPU)
TA-02N (PPU)
UMC UM6561(AF,BF,CF,F)-1 (NOAC)
PAL Famiclones ("dendy-timing")
Code:
MicroGenius MG-P-501 (CPU)
MicroGenius MG-P-502 (PPU)
UMC UA6527P (CPU)
UMC UA6538 (PPU)
TA-03NP1 6527P (CPU)
TA-02NP 6538 (PPU)
HA6527P (CPU)
HA6538 (PPU)
T1818P (NOAC) with external RAM
UMC UM6561(AF,BF,CF,F)-2 (NOAC)
PAL Famiclones (official PAL NES timings) exists, but they're
very rare. I know
only one, it have:
Code:
UMC UA6540 (CPU)
UMC UA6541 (PPU)
CPU RevisionsPPU Revisions
feos wrote:
Which very misleadingly classifies Brazil as PAL, while PAL-M actually uses NTSC timing. Because this happened to my country in that map, I don't know how accurate it is for all other countries.
BTW, I find it really amusing how pirates found a better way to make a PAL version of the NES/Famicom than Nintendo itself. I don't know if Nintendo intentionally made the PAL NES more different from the original than needed, as a form of region-locking, but judging by the many poor conversions that were made for the European market, I'm pretty sure that developers would've benefitted from better compatibility between the two systems.
Argentina (50Hz, 3.6MHz PAL) and Brazil (60Hz, 3.6MHz PAL) got their own special PPUs from UMC. Programs that run on Brazil's standard are definitely closer to 2C02 than UA6538.
Comparisons of geography are misleading. Better comparisons would involve cartograms by population or ideally (and unavailable) by total numbers of relevant consoles (i.e. with a cart slot) sold.
P.S. my page on the wiki:
nesdevwiki:User:Lidnariq/Known PPU revisions
Yes, PAL-M has the best of two worlds. The colors of PAL and the frame rate of NTSC. It's not PAL.
Except we were constantly converting from NTSC to PAL-M: video game consoles had transcoding circuits inside, rental VHS tapes were all NTSC,which our VCRs had to convert to PAL-M, so we didn't really see the supposed benefits of PAL-M.
PAL-M and N still use the near 3.5MHz color subcarrier so there's no improvement in color resolution over NTSC. It can only be transmitted longer over air without color getting messed up.
If they're anything like European PAL, they also have the 2 line comb filter for chroma as part of the spec. This lets TVs possibly try to recover more horizontal chroma bandwidth, seeing as the comb filter already does much of the separation in the vertical axis.
I hate to interrupt, but this thread is supposed to be about discussing NES 2.0 changes, not talking trivia about television systems in Latin America.

NewRisingSun wrote:
I have counted at least ten games now that require Dendy timing and are incompatible with RP2C02 and RP2C07 timing. "Incompatible" in one case means the game (西天取经 II - Journey to the West) crashes at the beginning of a boss battle.
Journey to the West was developed by TXC corp, so it confirms the theory.
NewRisingSun wrote:
Changes to
byte 12: TV System[...]
Meaning of Byte 13 if byte 7 bits 0-1==3: Extended console type
In hindsight, having a single byte for PPU would have been nicer. Sadly, I suspect it's not an option.
NewRisingSun wrote:
7 - Vs. Dual System with normal inputs
8 - Vs. Dual System with reversed inputs
I'm a little uncomfortable with stuffing two separate CPU's and two separate PPU's PRG and CHR ROM into a single .NES image. Unlike the other variations, this situation requires emulating two
screens as well.
In hindsight, I guess this is not too dissimilar from the Playchoice, but the secondary screen there is static and not relevant for gameplay.
How would Raid on Bungeling Bay be packed?
Emulating two CPUs and PPUs is not too difficult if the emulator design is modular. I don't think stuffing the two units' ROMs into one file is a problem at all provided it's properly documented how to separate them and no emulator does "its own thing" on that. Vs. Raid on Bungeling Bay is a Vs. Dual game with the second CPU only getting the dummy "mds-rb4-2 b.1a" ROM image. For iNES, you would pack the first 32 KiB PRG-ROM, then 24 KiB of padding, then the 8 KiB "mds-rb4-2 b.1a" ROM, then the 16 KiB CHR-ROM into the file. I've got it working right here.
Emulators can show both screens or just one of them. Showing just one is entirely justifiable, because the second unit running a different game session from the first is an unlikely option for home use, and players on the first playing against players on the second unit will necessarily show the entire game situation on both screens.
I am not sure what you mean by single PPU byte. You mean combining the Vs. PPU with the TV System field? I agree that could not be done without breaking backwards compatibility.
What I have not done is add a field for input/expansion device. I would have used to so-far unused byte 15 for that. That would make the "Vs. Mode" byte cleaner, since the Reversed and Weird control types would be moved out of it, and it would also relieve emulators of automatically assigning input devices using hash tables. But it was indicated on this board in the past that this would not be accepted and relegated to a metadata text file, so I left it out of the proposal, even though I would disagree and would find it nice.
NewRisingSun wrote:
players on the first playing against players on the second unit will necessarily show the entire game situation on both screens.
Are all Dualsystem games mirrored like this? I thought there'd be at least one that presents different views for the two players, such as games of partial information like Stratego or many card games or many FPS or RTS games, or things where the scrolling viewpoint differs like any racing game that isn't non-scrolling like Super Sprint or edge-triggered like Micro Machines. Even in a game of perfect information, something like doubles tennis might display the reverse angle, causing one side's controls to appear inverted if everybody's looking at the first machine's display.
I think Vs. Mahjong only shows each player's own stones. Of course, putting both screens side-by-side loses you the limited information as well, so unless an emulator outputs each emulated screen to a separate host display, the limited information aspect will be gone. Vs. Tennis indeed shows the reverse point of view, though not seeing the different point of view would not necessarily impact gameplay, even as the left/right buttons of the second unit would have to be reversed in that scenario.
But those are not issues for the NES 2.0 file format, as they would present themselves even when using MAME-like split ROMs.
NewRisingSun wrote:
Emulating to CPUs and PPUs is not too difficult if the emulator design is modular. I don't think stuffing the two units' ROMs into one file is a problem at all provided it's properly documented how to separate them and no emulator does "its own thing" on that. Vs. Raid on Bungeling Bay is a Vs. Dual game with the second CPU only getting the dummy "mds-rb4-2 b.1a" ROM image. For iNES, you would pack the first 32 KiB PRG-ROM, then 24 KiB of padding, then the 8 KiB "mds-rb4-2 b.1a" ROM, then the 16 KiB CHR-ROM into the file. I've got it working right here.
I've always been uncomfortable with mapper 99's "any padding is actually open bus" but given the constraints of the iNES format there was nothing to be done for it. Extending this such that
32 KiB PRG implies 1 CPU, no PRG bankswitching
48 KiB PRG implies 1 CPUs, PRG bankswitching at $8000
64 KiB PRG implies 2 CPUs, no PRG bankswitching
is ... well, I guess not really any worse.
I guess this does make we wonder if this behavior is better something baked into mapper 99 instead of into the header. We don't know of any DualSystem games that aren't mapper 99, and I'm unclear whether this "just pad and duplicate" behavior is something that should be generalized?
Quote:
will necessarily show the entire game situation on both screens.
Well ... sorta? at least Vs. Wrecking Crew displays the complementary information on both screens (near vs far is flipped)
NewRisingSun wrote:
Vs. Tennis indeed shows the reverse point of view, though not seeing the different point of view would not necessarily impact gameplay, even as the left/right buttons of the second unit would have to be reversed in that scenario.
Er. If you display both screens, then you don't need to reverse controls on the second unit. It's a problem specifically created by choosing to display just one screen.
Quote:
But those are not issues for the NES 2.0 file format, as they would present themselves even when using MAME-like split ROMs.
They're issues with saying that it's practical to display just one screen, which evidently has some sticking points.
I think Nocash is the only previous person to have attempted to put DualSystem emulation in a general-purpose NES emulator; if I'm right in that regard, I'd like his input on this too.
Quote:
What I have not done is add a field for input/expansion device. I would have used to so-far unused byte 15 for that.
I remember Zzo38 starting defining the external metadata format in response to being disappointed by that decision, but I forget basically everything else about that discussion. Link?
The discussion was
here. It quickly became philosophical. My point would be that the ROM header should contain everything needed to allow an emulator to run the game in a way that it can be played, without having to use a hash database. "in a way that it can be played" would include input devices, while it would not include cartridge codes, manuals, overscan and palette preferences and things like that. If the objection is to say that the real-hardware user has to know as well which input device he needs to plug into his console, I would reply saying that the user also has to know into which type of console --- NTSC, PAL, Dendy --- he is sticking his cartridge, and yet we have a TV System field.
As for the "who's going to update the headers in all the ROM files out there" problem (regardless of whether an "input devices" field is included or not), I would volunteer to make a NES-header correction utility (which in turn would of course need to have its database) that can be applied on an entire ROM collection. Once everything is finalized, new mapper numbers and all, that is.
NewRisingSun wrote:
The discussion was
here. It quickly became philosophical.
Wow, that was a useless discussion. Small wonder I'd forgotten specifics.
Quote:
My point would be that the ROM header should contain everything needed to allow an emulator to run the game in a way that it can be played, without having to use a hash database. "in a way that it can be played" would include input devices
I can't think of a good reason to
not include this information, but I think discussion about it should probably have its own thread.
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?
I'll post an input device proposal for byte 15 to a separate thread then.
Edit:
Done.
Should we add a Byte 13 reference to the CPU TEST mode being enabled? Not certain if test ROMs have been made yet, but it could also help with accurate emulation of the feature. Not certain if it's even emulated yet either.
That's quite esoteric. I suppose one could add a value for it, as long as it does not turn the whole proposal into a complete joke.
On another note, there already exist ROM images with 64 MiB and more in PRG-ROM size --- two OneBus plug-and-plays with exactly 64 MiB, and that "Coolgirl 320-in-1" multicart which has more than 64 MiB of PRG-ROM (and an
insanely complex mapper). NES 2.0 only allows up to 64 MiB at the moment, and 64 MiB are implicitly represented by zero PRG-ROM banks.
Not certain how the proposal would be a joke if it's an embedded feature (albeit hidden) within the processor itself. It also gives the emulator an opportunity to let the user know that the type of ROM requires the features enabled; and to provide a compatibility message.
It would become a joke if emulator authors started seeing the proposal as a wishlist for obscure features they have no intent of adding, and refuse to implement the header additions themselves for that reason. But okay, I have added Byte 13 value 02 to the proposal along with a disclaimer.
P.S. enumerating what test mode means:
* Normally, only reads from $4015 come from the CPU's internal data bus. There's some simple logic that controls whether the external data bus drives the internal data bus, and it's normally true during all other reads.
* When TEST is enabled, reads from the entire range from $4000-$401F are only from the internal data bus. THERE IS NO WAY TO USE EXTERNAL CONTROLLERS WHEN IN TEST MODE. Entirely separate controllers attached to the cartridge would be the only way.
** Now, Zzo38 has asked, and I think Quietust has confirmed, that TEST can be switched on a cycle-by-cycle basis, so it's possible to connect CPU A3 to TEST and change the isolated addresses to $4008-$400F, and $4018-$401F, but ... this option bothers me.
* When TEST is enabled, a write-only register at $401A and three read-only registers from $4018-$401A are enabled.
TEST is not present in the 2A03letterless. I don't know if it's present in the 2A03E and 2A03H.
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.
All right, out with it then.
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?
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.
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.
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.
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.)
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!

(ducks away))
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".)
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)
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.)
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.)
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?
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.
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.
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)
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.
NewRisingSun wrote:
I would still like to solicit more input on how to deal with ROMs with more than 64 MiB of PRG-ROM.
My suggestion:
1- Anything released that doesn't provide true random access to ROM is out of scope for stuffing into .nes (e.g. bare NAND flash, CompactFlash, SD card)
2- 256 MiB NOR FLASH is already really expensive ($18/@1600). Market forces give every reason to believe no larger NOR FLASH will be ever sold.
3- I like rainwarrior's floating-point-ish option.
Quote:
yielding a much more streamlined implementation.
To my disappointment, I feel like mapper 185 already
case cast a vote in favor of making the emulator's code base a mess in preference to baking in padding.
Quote:
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.
But the 16 KiB banks are an artifact anyway, given the number of games that do 8 KiB banking. Is it really all that different to quantize things to 8 KiB vs 32 KiB?
Ok, then trimmed Vs. Mahjong and Bungeling Bay it is. I hope to post the updated proposals this weekend.
Here is the updated proposal, as promised.
Byte 7: Flags 7
Code:
7654 3210
---------
NNNN SSTT
|||| ||++- Console type (see below)
|||| ++--- NES 2.0 identificator (binary 10)
++++------ Upper four bits of mapper number
Console types:
$00 Regular NES/Famicom/Dendy home console, byte 13 unused
$01 Vs. System, byte 13's two nibbles indicating palette and protection/type
$02 Playchoice 10, byte 13 unused, three Misc. ROMs specified in byte 14 (8 KiB INST, 16 bytes PROM Data, 16 bytes PROM CounterOut).
$03 Extended, byte 13 further describing the console
Byte 9: Upper bits of ROM size
Code:
7 0
---------
CCCC PPPP
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
If P/C has the value $F, header bytes $4/$5 changes meaning from number of 16 KiB/8 KiB PRG/CHR banks to the following floating-point-like format:
7 0
---------
EEEE EEMM
|||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
++++ ++--- Exponent (2^E), 0-63
The actual PRG- or CHR-ROM size therefore becomes 2^E * (MM*2+1). This allows for ROM sizes larger than the current maximum of 64 MiB without too much padding.
Byte 12: TV System
Code:
7654 3210
---------
.... ..TT
++- Frame timing
0: RP2C02 (NTSC)
1: RP2C07 (PAL licensed)
2: RP2C02 and RP2C07 (game self-adjusting or doesn't matter)
3: UMC 6527P (PAL with NTSC-like timing, also known as "Dendy" or "Micro Genius" mode)
Byte 13 if Byte 7 AND $03 == $01: Vs. Hardware
Code:
Bits 0-3: Palette (unchanged from current spec)
Bits 4-7: Vs. Mode
$0 Normal- no special mode(s)
$1 RBI Baseball (protection hardware at port 5E0xh)
$2 TKO Boxing (protection hardware at port 5E0xh, different from 1)
$3 Super Xevious (protection hardware at port 5xxxh)
$4 Vs. Ice Climber Japanese (protection: controller bit $08s always 1)
$5 Vs. Dual System
$6 Vs. Raid on Bungeling Bay (dual CPU, protection: controller bit $08s always 1)
Byte 13 if Byte 7 AND $03 == $03: Extended console type
Code:
$00 NES/Famicom
$01 Vs. System
$02 Playchoice 10
$03 Bit Corporation Creator (normal Famiclone but with decimal-mode-supporting CPU)
$04 VT01 Monochrome
$05 VT01 Red/Cyan
$06 VT02
$07 VT03
$08 VT09
$09 VT3x
$0A VT36x
$0B-$FF Reserved for future expansion
Byte 15: Input/expansion port device
Code:
$00 Unspecified, use NES standard controllers
$01 Famicom controllers with Microphone
$02 NES Four Score/Satellite with two additional standard controllers
$03 Famicom Four Players Adapter with two additional standard controllers
$04 Vs. System
$05 Vs. System with reversed inputs
$06 Vs. Pinball (Japan)
$07 Vs. Zapper
$08 Zapper
$09 Two Zappers
$0A Bandai Hyper Shot
$0B Power Pad Side A
$0C Power Pad Side B
$0D Family Trainer Side A
$0E Family Trainer Side B
$0F Arkanoid Paddle (NES)
$10 Arkanoid Paddle (Famicom)
$11 Two Vaus Controllers plus Famicom Data Recorder
$12 Konami Hyper Shot
$13 Coconuts Pachinko Controller
$14 Exciting Boxing Punching Bag
$15 Jissen Mahjong Controller
$16 Party Tap
$17 Oeka Kids Tablet
$18 Sunsoft Barcode Battler
$19 Miracle Piano Keyboard
$1A Pokkun Moguraa
$1B Top Rider
$1C Double-Fisted
$1D Famicom 3D System
$1E Doremikko Keyboard
$1F R.O.B. Gyro Set
$20 Famicom Data Recorder (don't emulate keyboard)
$21 ASCII Turbo File
$22 IGS Storage Battle Box
$23 Family BASIC Keyboard plus Famicom Data Recorder
$24 Dongda PEC-586 Keyboard
$25 Bit Corp. Bit-79 Keyboard
$26 Subor Keyboard
$27 Subor Keyboard plus mouse (3x8-bit protocol)
$28 Subor Keyboard plus mouse (24-bit protocol)
$29 SNES Mouse
$2A Generic multicart
$2B Two SNES controllers replacing the two standard NES controllers
Input Device Notes:
- Does not include input devices that attach to cartridge hardware.
- Most games only support one input device, making this value entirely unambiguous for them. For the few (mostly homebrew) games that allow selecting devices, this becomes a "default" input --- pick one, or don't and leave it at $00, letting the user decide in any case.
Device-specific notes:
- "Famicom controllers with Microphone": Use only if the microphone is actually used.
- "Vs. System": Used for both Unisystem and Dual.
- "Famicom Four Players Adapter": Use only if the games use the 3P and 4P controllers for independent input, not if they're just doubling 1P and 2P input.
- "Two Zappers": Becomes just "Zapper" if the user has only one mouse and does not use netplay. Even when emulating two Zappers, keep emulating 1P controller (the $4016 bits do not overlap, after all) so that player may choose to use it as well.
- "Two Vaus Controllers plus Famicom Data Recorder": For Arkanoid II.
- "Double-Fisted": Used for Crazy Climber and Smash TV. Implies NES Four Score for Smash TV's two-player double-fisted mode, which does not bother Crazy Climber.
- "R.O.B. Gyro Set": See what Nestopia does there.
- "Subor Keyboard": Implies Tape Recorder.
- "Generic multicart": Emulate this as "Zapper in Famicom Expansion port", keeping 1P and 2P controllers attached. This value exists to signal to emulators so-inclined to detect the handful of common expansion-device-using multicart games, for example by comparing ROM strings involving controller read code, and auto-select the device for the selected game.
ROM layout for Vs. Dual games:
- Most Vs. Dual games have unique 32 KiB PRG-ROM for each unit. Include both sequentially for 64 KiB of PRG-ROM.
- If both units have the same CHR-ROM data, include it only once.
- Vs. Mahjong has 24 KiB of PRG-ROM for each unit. Include both sequentially for 48 KiB of PRG-ROM, mapping each 24 KiB to each CPU's $A000-$FFFF, keeping CPU $8000-$9FFF as open bus.
- Vs. Raid on Bungeling Bay has 32 KiB of PRG-ROM for the first unit, and 8 KiB of PRG-ROM for the second unit. Include the first 32 KiB, then the second unit's 8 KiB without padding to form 40 KiB of PRG-ROM, denoted by setting byte 9's LSB to $F and byte 4 to $36. Map the first unit's 32 KiB to CPU $8000-$FFFF, the second unit's 8 KiB to CPU $E000-$FFFF, and keep the second unit's CPU $8000-$DFFF as open bus.
---
Obiter dictum: Note what I wrote about Playchoice 10 and Misc ROMs. The Extended Console Type now has values 0-2 identical to what Byte 7 bits 0-1 already specified for congruity.
I did not include a proposal for >64 MiB ROM sizes: the only such ROM known to me is the Coolgirl homebrew multicart, which has 66.5 MiB and would be nasty to pad to a power of two, so I am still undecided on what to do with that. Here is my current Nintendulator-NRS build, which includes an updated Header Editor incorporating all aspects of this proposal including the new byte 9. (It does not actually emulate all those expansion devices, yet.)
Edit: I have incorporated Rainwarrior's floating-point-ish proposal and modified the ROM layout description for
Vs. Raid on Bungeling Bay to make use of it. This could also be used to contain Galaxian's 8 KiB of PRG-ROM without padding. Doing so would however break compatibility with existing emulators that would otherwise run the game, one of NES 2.0's stated goals. It's less of an issue for
Vs. Raid on Bungeling Bay because no previous emulator runs the game from an iNES-format image anyway.
NewRisingSun wrote:
the only such ROM known to me is the
Coolgirl homebrew multicart, which has 66.5 MiB
?
I see a S29GL512 64 MiB flash, two RAMs (K6F2008 and U?62256), four voltage translation ICs (two 74ALVC16245s and two TI parts), and an Altera MAX 2. Does the MAX 2's fusemap somehow encode 2.5MiB of ROM?
The actual size of the UNIF PRG0 chunk is 0x4280000 bytes. Make of that what you will.
That's ... weird.
One, the battery is clearly made to be replaced, and I don't see any significant bulk capacitance to retain the contents of the RAMs when it's missing, and two, in the pictures of the PCB I'm pretty certain I only see the backed-up power line getting to the 32KiB RAM, not the 256KiB SRAM.
(Thirdly, 288KiB ≠ 2.5MiB anyway)
edit: Ninja'd by an edit.
I found
ClusterM's build tool to generate a custom coolgirl multicart. It appears to
just generate a flat 256 MiB UNIF PRG0...
My UNIF ROM image came from a "Non-GoodNES" pack. I suppose somebody just trimmed it, or it came from an earlier version of the build tool.
I have updated the proposal with Rainwarrior's ROM size proposal, which I like very much (it took me a while to understand it).
ClusterR's web site also seems to allow (in javascript) the generation of images to flash onto a coolgirl flashcart. It's conceivable that it doesn't add any padding, or trims the padding.
NewRisingSun wrote:
"Vs. System": Used for both Unisystem and Dual. Differs from standard controllers in that "start button 1/2/3/4" are "1P Select/1P Start/2P Select/2P Start".
This bit seems to contradict the wiki which says that 1 & 3 are for player 1, and 2 & 4 are for player 2.
The only examples of arcades that I found in pictures were:
A) The DualSystem red tent - 1/2/3/4 are all together on the right side and don't really look like they are associated with either P1 or P2
B) A number of unisystem arcade cabinets which kind of look like "1" is P1's button, and "2" is P2 (which matches the wiki). But these have no 3/4 buttons, and really 1/2 just look like they are meant to be used as 1/2 player mode selection at the start and nothing else.
Emulation wise, it's "easier" to map the buttons to what the wiki says at the moment (1/3 = P1, 2/4 = P2), since that maps directly to the standard NES controllers.
For the record, Nestopia uses these mappings:
1 = P1 Start, 3 = P1 Select (e.g same as wiki, but switches the select/start bits)
2 = P2 Start, 4 = P2 Select
I don't really think there's a "perfect" way to map these, but I was about to commit my current changes/fixes w/ P1 as 1 & 3 and P2 as 2 & 4, which doesn't match the proposal, so I figured I should bring it up.
Sour wrote:
This bit seems to contradict the wiki which says that 1 & 3 are for player 1, and 2 & 4 are for player 2.
The two different official schematics—one of the mainboard, and one of the wiring harness—disagree as to what bit comes in where.
The wiring harness specification ("VS_Wiring.pdf") says that pins 8/9/10/11 are S SELECT 1/2/3/4 in order... but also that there is no button associated with S SELECT 3/4.
The MDS mainboard schematic ("VSSCHEM.pdf") says that pins 8/9/10/11 are S SELECT 1/3/2/4 in that order.
Regardless, the MDS mainboard schematic says that pins 8/9 are read by S 2A03 via $4016, and pins 10/11 are read by S 2A03 via $4017... and that $4017 is player 2 and $4016 is player 1, unlike everything I've heard before?
I made a list of how the various games use the $4016 and $4017 serial bits, and what they call them:
Code:
Game $4016 $04 $4016 $08 $4017 $04 $4017 $08
Normal NES 1P Select 1P Start 2P Select 2P Start
Input type: "$04 Vs. System":
Vs. Balloon Fight 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Baseball 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Mahjong 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Pinball 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Slalom 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Super Mario Bros. 1P Start ("blue") - 2P Start ("green") -
Vs. Wrecking Crew 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Tennis 1P vs. Comp ("blue/1") 2P vs. Comp("pink/3") 1P vs. 2P ("green/2") 2P vs. 2P ("yellow/4")
Input type: "$05 Vs. System with reversed inputs":
Atari R.B.I. Baseball 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Battle City 1P Start ("") - 2P Start ("") -
Vs. Clu Clu Land 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Dr. Mario 1P Start ("blue") - 2P Start ("green") -
Vs. Golf (2x Start) 1P Start ("blue/1) - 2P Start ("green/2") -
Vs. Gradius 1P Start ("") - 2P Start ("") -
Vs. Ice Climber 1P Start ("blue/1") - 2P Start ("green/2") -
Vs. Raid on B-Bay 1P Start ("1") - 2P Start ("2") -
Vs. Soccer 1P Start ("blue/1") - 2P Start ("green/2") -
Ninja Jajamaru-kun 1P Start ("1") 2P Start ("3") - -
Super Sky Kid 1P Start ("1") 2P Start ("3") - -
Vs. Golf (4x Start) 1P Stroke ("blue/1) 1P Match ("pink/3") 2P Stroke ("green/2") 2P Match ("yellow/4")
Super Xevious, Vs. Castlevania, Vs. Duck Hunt, Vs. ExciteBike, Vs. Goonies, Vs. Gumshoe, Vs. Hogan's Alley, Vs. Mach Rider, Vs. Star Luster, Vs. Top Gun: Single-player only.
Vs. Tetris/Vs. TKO: Game mode is selected via cursor and not decided by pressing which button.
In other words, "Vs. System with reversed inputs" reverses the D-Pad and B/A buttons but not the start/select buttons. Then everything neatly falls into place. Pretty much the only oddities are Sky Kid and Jajamaru wanting to start two-player mode with button 3, which they even call by that number, rather than with button 2. In any case, the proposal does not require implementing Vs. Controls in any particular way, only that there are two mappings, normal and reverse. It's probably best to present the user with the colors and button names that the games present, though.
Edit: I have updated the Nintendulator-NRS build to support the new byte 9 as well.
Thanks for taking the time to make that list - saves me a lot of headache when double-checking the setup I have.
Just one tiny thing, Tetris does need swapped controllers in a sense, otherwise P1 ends up being on the right side of the screen during gameplay.
Since GoodNES' Vs. ROM images are useless for Vs. Dual games and don't have NES 2.0 headers for Unisystem games, I have made the attached batch file 'n headers to convert MAME's Vs. ROM sets to the NES 2.0 format according to the proposed specification. For games with odd ROM sizes, I am producing both padded and trimmed versions, the latter making use of the floating-pointish way of specifying the ROM size.
As of the latest commit, Mesen supports all of the proposed changes (I think). Headers specifying hardware Mesen itself doesn't support is ignored for now. VS System support is complete (including DualSystem).
Slightly unrelated, but I've also added support for ~55 mappers in the 256+ range (thanks for making the Wiki page with the UNIF<->NES 2.0 mappings, was extremely helpful)
Quote:
The actual PRG- or CHR-ROM size therefore becomes 2^E +MM*2+1.
This should be
2^E * (MM*2+1), I think?
I have corrected the formula.
That's nice that somebody appreciates the wiki additions.
Edit: Added the "Two SNES Controllers" entry to the Input Device list.
A Mesen version with support for the additional fields in this proposal has now been released for some time, so I wonder if the proposal should be considered accepted and added to the wiki.
Is there any interest in using the upper nybble of Byte 12 or 14 that would allow for the designation of expansion audio with hardware not orignally intended for that hardware? This might come into play if a homebrew author makes a game that runs off Mapper 4 but uses VRC6 sound. Or there is an interesting pirate version of a particular game that left expansion audio data writes in the game but the cartridge hardware does not support. You could designate the upper nybble like this :
0 - No expansion audio
1 - VRC6
2 - VRC6 Alt
3 - VRC7
4 - Sunsoft 5B
5 - Namco 163
6 - FDS
7 - MMC5
8 - uDP7756
9 - uDP7755
10 - M50805
11 - UM5100
12-15 reserved for future use
I know that the 16-byte header is running out of bits, but maybe this is worth considering.
You cannot just add any particular sound chip support to any existing mapper because of address space collision. For example, VRC6 uses Addresses $9000-$9003, $A000-$A002, $B000-$B002 with an address mask of $F003, while the MMC3 uses the same address range with an address mask of $E001. Even if you emulated each with the narrowest of address masks, the same address would still map to a register in both chips. You would have to thoroughly redraw each chip's address map for this two work, and the information on how this would be done cannot be conveyed by merely specifying the presence of an additional sound chip, as it would have to be mapper-specific. Multiple expansion sound chip support barely works in NSF players, and only because NSF players do not emulate entire mappers, only the small subset dealing with sound generation. If a homebrew cart wants to use a hybrid mapper combining features of several legacy mappers, it should assign a new mapper number for that, instead of using precious header space.
Great Hierophant wrote:
Is there any interest in using the upper nybble of Byte 12 or 14 that would allow for the designation of expansion audio with hardware not orignally intended for that hardware?
No. Just create a new mapper for this. Using these 4 bits in the header creates a nonsensical combinatorial explosion with every single mapper. This has no existing use cases. If you want to experiment with these combinations, hack an emulator, or build the cartridge. When you've got something worth emulating, come back and propose the mapper for that particular combination.
I understand now, it just simply won't work without defining new hardware and therefore should use a new mapper.

Running an NSF and running a game are different things.
I think we may need to add a few peripherals to the list. Let me explain the reasons why :
1. R.O.B. Block Set
Used for Robot Block/Stack-Up. One of the modes of this game is a puzzle mode where you have to place the blocks in a certain pattern and get ROB to move them until it matches the pattern shown. This could be simulated by simulating ROB's limitations, that if cannot just take the block underneath another block, he must take the top or take all of them.
2. Power Glove
Used for Super Glove Ball and Bad Street Brawler. These game support the standard controller but actually can alternatively were intended to use the motion capture technology of the Power Glove. Super Glove Ball's manual describes the alternative behavior of using hand motions to control the glove in the game more naturally than the standard controller. Bad Street Brawler's support is obscure and marginal, but it does exist :
https://www.badgamehalloffame.com/blog/ ... t-brawler/3. U-Force
The U-Force Power Games prototype is the only game known to be U-Force aware and can use the analog mode, where the device tries to do more than just emulate a standard controller :
http://nintendoage.com/forum/messagevie ... adid=191313 & 4 may be impossible to emulate without a Microsoft Kinect or similar device, but it should be here for completeness' sake.
4. More than One Control Scheme
Multi-carts have an issue where they may more than one setup. Super Mario Bros./Duck Hunt may use two standard controllers or one standard controller and a zapper. Super Mario Bros./Duck Hunt/World Class Track Meet could use two standard controllers or one standard controller and a zapper or a standard controller and Power Pad Side B. How should you designate these ROMs, especially the last one?
- Block Set differs from Gyromite in that the main game really does take place off the game screen. There's no point in emulating that. I only included Gyromite because Nestopia has an emulation for it, and because it makes a bit of sense for that game.
- Unknown how one would even begin emulating that. Until that is known, it should not be added.
- Same.
- That's exactly what $2B "Generic Multicart" conveys. Its implementation is entirely up to the emulator. Emulating two controllers plus one zapper --- the hardware bits do not overlap --- is the simplest way and will catch almost all cases, the NES Power Set being an exception.
The proposal has not been formally adopted, so I do not want to add any off-putting edge cases now.
Expected input device doesn't sound like "description of the cartridge hardware needed to emulate it", more "this is a substitute for reading the manual".
Oppose.
, after all
Yeah, the NES header is not supposed to be an encyclopedia about the game, it's supposed to contain information describing the hardware inside the cartridge.
NewRisingSun wrote:
[*]Block Set differs from Gyromite in that the main game really does take place off the game screen. There's no point in emulating that. I only included Gyromite because Nestopia has an emulation for it, and because it makes a bit of sense for that game.
I did not understand how ROB emulation worked on Robot Gyro, and now that I know how it works it does not make sense for Block Set at this time. However, I could see someone one day trying to simulate how ROB works for both games in a more involved manner. It could work something like this :
You would see an image of ROB on a second screen. You would see his arms move and open and close according to your instructions. Sound would be optional

You can use estimated times for long it takes ROB to move from point to point, how long it takes a gyro to spin to its maximum rotational speed and how long it will sit on the land before it falls off. Perhaps you may want to include some randomness in the timing. Similarly, you can use ROB with the Block Set to simulate the positioning ROB would need to do to move blocks from one podium to another. ROB may not be able to lift all five blocks at once or over the full range of his body without dropping them, so the emulator author might have some fun with that.
So, how are we going to emulate punching this :

As for Myask's concern, if we were just dealing with the NES stuff I do not think this would be necessary. The number of games that require non-standard controllers is small and well-known. But Famicom opens up a large can of worms with lots of weird peripherals that ordinary gamers don't really know about. They may think a game is broken when their standard controller is not working. The language barrier tends to make for a lot of ignorance, so I see this byte as helping emulator authors inform users that "the game is not broken, but it does not control in the way you may anticipate."
Myask wrote:
doesn't sound like "description of the cartridge hardware needed to emulate it"
tokumaru wrote:
it's supposed to contain information describing the hardware inside the cartridge.
That rule of thumb has already been betrayed by the NTSC/PAL bit in iNES1, and blown out of the water by marking specific Vs. System PPUs in NES2
I really can't see any non-circular argument why marking properties of the console is something that should be there, but the expected peripherals shouldn't.
NTSC/PAL bit matches the lockout chip. And I thought Vs. System games put the PPU on the game board, not the system board.
tepples wrote:
NTSC/PAL bit matches the lockout chip.
The lockout chip is not necessary for emulation. After all, it doesn't mark PAL region 1 vs PAL region 2. Instead, the bit in the header is very specifically and exclusively for marking 2A03+2C02 vs 2A07+2C07.
Quote:
And I thought Vs. System games put the PPU on the game board, not the system board.
Only the ones that added extra mapper ICs. There are plenty of original "mapper 99" Vs. System games (distributed as piles of ROMs) that require exactly one of the 2C04s.
This has been discussed
previously, and Myask/tokumaru's posts do not indicate having considered the arguments made in favor then.
There should be an input device field because...
- several emulators already select expansion devices automatically based on hash tables;
- because it is user-friendly to do so.
Hash tables are bad because they tie the feature to a specific set of ROM images and are not ROM-hack-/homebrew-friendly. Not automatically selecting input devices ("read the manual") requires user action for every game with expansion devices. This is bad because...
- most emulator users have no access to manuals, especially non-Western ones, or cannot read them because the manuals are not in English;
- per-hand selection for every game is cumbersome when trying out a whole set
- manuals do not always contain that information, such as whether the mouse expected by an educational computer cartridge uses a 3x8 bit or 1x24 bit protocol.
The single reason given against the field has been normative rather than practical: headers "should" only contain
"the function of everything inside the Game Pak shell". It has not been justified why that should be or should remain to be the standard. It is abstract rather than based on usability criteria, either for the user or the emulator, and violated already by other header fields. I agree that a header should not be an indiscriminate "encylopedia about the game", but if several emulators already use hashes to supplement that information, it is an indication that it probably should be in the header, just as emulators having used hashes to distinguish mapper variants justified adding submappers.
The input device proposal in this thread is space-efficient, emulator- and ROM-hack-friendly, and the field's value is entirely unambiguous for almost every game and multicart, the only exception being the small number of homebrews that allow the user to select from many different controller options. For them, the input device field would reflect what those games default to. The field has already been implemented by Mesen.
I propose to merge this topic into the older one:
viewtopic.php?f=3&t=2090I had that one in the bookmarks, and I didn't know that there is an important discussion about the matter in another topic.
Anyway, I propose to extend byte 12 this way:
Code:
Byte 12:
7 0
---------
xdpn xxBP
The byte consists of two nibbles. The higher nibble describes which systems are supported, the lower nibble describes which system is preferred.
If higher nibble is 0, use legacy interpretation:
0000 0000 - NTSC only
0000 0001 - PAL only
0000 0010 - Supports NTSC and PAL, but NTSC is preferred
0000 0011 - Supports NTSC and PAL, but PAL is preferred
Otherwise, higher nibble describes supported systems:
d - Dendy
p - PAL
n - NTSC
Lower nibble (bits BP) describes preferred system:
00 - NTSC (a legacy emulator will use NTSC)
01 - PAL (a legacy emulator will use PAL)
10 - Dendy with fallback to NTSC (a legacy emulator will use NTSC)
11 - Dendy with fallback to PAL (a legacy emulator will use PAL), or just reserved
If the lower nibble chooses the system which is not marked as a supported system in the higher nibble, fallback to the legacy behavior. Bits 2,3 and 7 should be ignored by emulators, and should be 0 in ROMs.
It is much more flexible than it was proposed
here, and it covers all the use cases which are covered by the
new NSFe regn section (I believe that NSFe could be extended the same way, a separate section is an overkill).
Examples of usage. There are a lot of Unchained Melody multicarts which were intended to run on famiclones like Dendy. These ROMs could use this bitset:
0100 0010 - it states that it supports Dendy only, and that the preferred system is Dendy. Legacy emulators will use NTSC.
I have created the
Unchained Nostalgia demo (based on the multicart's menu). I have added support of NTSC and PAL systems, but Dendy is still the preferred one. So:
0111 0010 - all systems are supported, Dendy is the preferred one, legacy emulators will use NTSC.
I oppose, because of one criterion: the header should be unambiguous; every game should have one header with values that are correct for that game, with any other being incorrect. That allows "good" ROMs to have one unambiguous CRC32
including the header. All the current and proposed fields meet that criterion, including the input device field
as previously described. Denoting what is preferred on the other hand is inherently subjective and therefore ambiguous. You could have three times the same ROM image with three different headers because somebody prefers NTSC/PAL/Dendy, and have all three being correct according to the definition.
I have not much to say about it as an iNES revision. I'll respond to the request to alter the 'regn' field though:
I don't think this is a useful addition. There is already "bitfield of supported systems" and "preferred system". What you're proposing seems to be partially approaching "ranked set of preferred systems" which I don't really see a good purpose for, and I think has ramifications that are an encumbrance on the implementation for how to correctly handle that ranking.
If you want Dendy or NTSC but prefer Dendy, then leave the PAL support bit clear, and vice versa. Why is that insufficient? You really have a use case where an NSF is going to support 3 regions differently and you need to prefer 2 of them over the 3rd?
The 'regn' field also has the option to omit preference, in which case all supported options are valid, and a user preference option might be supplied. I think a useful set of user options to provide are: Auto (emulator chooses based on preference if supplied, otherwise arbitrary), Prefer X (user chooses system X, it is used if supported and no preference is supplied, otherwise same as Auto), Force (user chooses and the supplied options are ignored).
The point of the preference was to indicate that there is one "best"version; if they can't get that every other supported version is some kind of compromise. I think it is splitting too fine a hair to want to rank those compromises too.
Legacy emulators won't support any of this, so I don't think they're a concern. (In some cases, providing multiple ROMs that differ only by header is a valid way to provide both options to users, too.)
NewRisingSun wrote:
Denoting what is preferred on the other hand is inherently subjective and therefore ambiguous.
It's not subjective. The preferred system is the system which works perfectly with the ROM. The other ones are supported, but not perfect. For example, in case of Unchained Nostalgia, in case of PAL you will have a slightly wrong sound on noise channel (because it is not possible to make it absolutely the same on three systems), in case of NTSC you may notice artifacts of speed adoption (it skips every 6th frame on NTSC systems to have the same speed as on Dendy). So, it is perfect only on Dendy, but it also works nicely on PAL and NTSC systems. That's why Dendy is preferred, but NTSC and PAL also are allowed. This bitfield is not for storing some settings by a user. It is intended to describe what is supported by the ROM, and what is the best option.
VEG wrote:
For example, in case of Unchained Nostalgia, in case of PAL you will have a slightly wrong sound on noise channel (because it is not possible to make it absolutely the same on three systems), in case of NTSC you may notice artifacts of speed adoption (it skips every 6th frame on NTSC systems to have the same speed as on Dendy). So, it is perfect only on Dendy, but it also works nicely on PAL and NTSC systems.
Then just denote it as "Dendy". I do not see the value of also denoting that it sort-of works on NTSC and PAL.
Addition:
VEG wrote:
It is intended to describe what is supported by the ROM
I faced a similar issue when designing my input device field: Do I want to describe all the things a ROM might support (turning the header into an "encyclopaedia about the game"), or merely what device an emulator must virtually plug in for the user to actually play the game, without using hash tables? After making the choice unambiguous for all games (the only one supported, or the default one in the case of several options), I chose the latter for a much more concise, easy-to-implement, space-saving field.
VEG wrote:
It's not subjective. The preferred system is the system which works perfectly with the ROM. The other ones are supported, but not perfect. For example, in case of Unchained Nostalgia, in case of PAL you will have a slightly wrong sound on noise channel (because it is not possible to make it absolutely the same on three systems), in case of NTSC you may notice artifacts of speed adoption (it skips every 6th frame on NTSC systems to have the same speed as on Dendy). So, it is perfect only on Dendy, but it also works nicely on PAL and NTSC systems. That's why Dendy is preferred, but NTSC and PAL also are allowed. This bitfield is not for storing some settings by a user. It is intended to describe what is supported by the ROM, and what is the best option.
It is suggestive. You call the sound on the noise channel "wrong", this is your opinion and it could be agreed otherwise. You say you notice artifacts of speed adoption, this is just your opinion.
rainwarrior wrote:
I have not much to say about it as an iNES revision. I'll respond to the request to alter the 'regn' field though
According to NSFe, I propose to extend the meaning of the byte $0006 in the INFO section. regn section would not be required at all if the byte $0006 is extended in a backward compatible way.
rainwarrior wrote:
Legacy emulators won't support any of this, so I don't think they're a concern.
Legacy emulators already treat two bits from this byte. So, if we extend this byte, we should take into account original meaning of these two bits. That's why you set Dendy as a preferred system and another system as a fallback. Some emulator which don't support Dendy at all, and it will have information which system should be used in this case, for example.
rainwarrior wrote:
I think has ramifications that are an encumbrance on the implementation for how to correctly handle that ranking.
Actually, it makes things easier. Especially for cases when an emulator doesn't support Dendy and needs to fallback to NTSC or PAL. It will just use original meaning of bits 0 and 1, and voila! If Dendy is supported, just treat the byte as two nibbles which describe the same things as described in the regn section of the latest NSFe specification.
NewRisingSun wrote:
Then just denote it as "Dendy". I do not see the value of also denoting that it sort-of works on NTSC and PAL.
rainwarrior already has provided an example how to use this information:
rainwarrior wrote:
I think a useful set of user options to provide are: Auto (emulator chooses based on preference if supplied, otherwise arbitrary), Prefer X (user chooses system X, it is used if supported and no preference is supplied, otherwise same as Auto), Force (user chooses and the supplied options are ignored).
Bregalad wrote:
You say you notice artifacts of speed adoption, this is just your opinion.
You can notice it when scrolling is used. It is not as smooth as it is when Dendy mode is used. The difference is subtle, but it exists and you can notice it.
VEG wrote:
rainwarrior already has provided an example how to use this information:
I asked about the
value of this information, meaning the
why, not the
how. To put it bluntly: if it is supposed to be run on Dendy, then that is all the emulator needs to know --- who gives a shit if it also can be run on NTSC and PAL?
Addition:
As for the subjectivity part, I would
not know whether some unlicensed games are "preferred" to run as NTSC or Dendy. For example, I know that because later Waixing games were sold in mainland China for the Subor famiclones, Dendy is the "correct" target platform, but listening to the music speed, I would "prefer" NTSC.
NewRisingSun wrote:
To put it bluntly: if it is supposed to be run on Dendy, who gives a shit if it also can be run on NTSC and PAL?
If an emulator don't support Dendy, it should know which system it should use. If a user prefers some specific system for some reason, but don't want to force it when it is not supported by a ROM, the information about supported systems would be useful for an emulator.
NewRisingSun wrote:
but listening to the music speed, I would "prefer" NTSC.
It doesn't matter what you prefer (but you can still "force" your preferred system). The only right music speed is on Dendy. In case of Unchained Melody it is easy to check. It's a cover to a well-known melody, and it is as slow as on the cover on Dendy.
VEG wrote:
If an emulator don't support Dendy, it should know which system it should use. If a user prefers some specific system for some reason, but don't want to force it when it is not supported by a ROM, the information about supported systems would be useful for an emulator.
Both being highly contrived scenarios.
VEG wrote:
It doesn't matter what you prefer (but you can still "force" your preferred system)
Okay, now I understand nothing. I am supposed to denote a preferred system, but it does not matter what I prefer?
NewRisingSun wrote:
Both being highly contrived scenarios.
Sometimes it is not easy to add Dendy support to an emulator. For example, it took a lot of time to add it to the FCEUX, because FCEUX had a lot of hardcoded things throughout the whole codebase. In this case, an emulator could use information provided.
NewRisingSun wrote:
I am supposed to denote a preferred system, but it does not matter what I prefer?
The header will provide the only right preferred system. You can force another system in the emulator if you wish, as it was written before.
In the case of NSF, dual region was part of the spec from the beginning. The question of preference for the most part didn't come up; I think Streemerz was the first dual region that had a reason to prefer PAL, and it's probably the only such NSF worth talking about still. It probably should have been exclusive (as should have the expansion fields too) but this is its history.
I don't really want to implement this thing you thought of. OK it's "backwards compatible" with the previous one, that's a nice property for an addition to have, but that's not a reason that we need to stuff yet another thing into the NSF specification. I created 'regn' and implemented it. I don't really want to assist creating another redundant way to do this. All this proposal does is making parsing more complicated, without really adding anything that was needed.
For iNES, I do think it's important to put region in there, but that's the only critical thing to me. The rest is decreasingly useful. I only put preference into NSFe because it's an inherently extensible format, it's an entirely optional addition to the file. Not really comparable to iNES.
Well, FCEUX has since added Dendy support, and I know of no other major emulator without Dendy support. The scenario is still highly contrived because it requires adding support for the proposed field
without also adding support for Dendy timing.
VEG wrote:
Sometimes it is not easy to add Dendy support to an emulator.
Additional header fields should not be added for the sake of helping emulator authors avoid implementing necessary features.
VEG wrote:
The header will provide the only right preferred system. You can force another system in the emulator if you wish, as it was written before.
I am getting completely confused by your use of the term "preferred". Preferred by whom?
I
think you mean to say "Dendy is correct, but the game can also run without serious glitches on NTSC/PAL as a second-best option". That might be less subjective, but we still have the problem that this information is more encyclopaedic than useful:
VEG wrote:
If a user prefers some specific system for some reason, but don't want to force it when it is not supported by a ROM
A user wants to run a game on an emulated console it was not made for? Who does that? Highly contrived, and does not justify adding a header field. The only application I see for this is running PAL/Dendy games at 60 Hz for better VSync purposes, and there are better ways of achieving that in an emulator.
Quote:
I asked about the value of this information, meaning the why, not the how. To put it bluntly: if it is supposed to be run on Dendy, then that is all the emulator needs to know --- who gives a shit if it also can be run on NTSC and PAL?
All ROMs can be run with NTSC, PAL and Dendy. It's just that the results might be disastrous, for example running Battletoads PAL on NTSC will not get the games running, but you can still do it.
It's not part of the ROM on which system it's run - the ROM is a digital represntation of the cartridge. Lockout chips makes it possible to objectively say which video system the cartridge should be used on. But for unlicenced games there's no such a thing - anything will be subjective.
NewRisingSun wrote:
The scenario is still highly contrived because it requires adding support for the proposed field without also adding support for Dendy timing.
Wrong. This field is already supported by the emulators which know about NES 2.0. For example, look at this code from the Mesen (before it adopted your suggestion):
Code:
bool IsPalRom()
{
switch(GetRomHeaderVersion()) {
case RomHeaderVersion::Nes2_0: return (Byte12 & 0x01) == 0x01;
case RomHeaderVersion::iNes: return (Byte9 & 0x01) == 0x01;
default: return false;
}
}
Or another example from its debugger:
Code:
public bool IsPalRom()
{
switch(GetRomHeaderVersion()) {
case RomHeaderVersion.Nes2_0:
return (_bytes[12] & 0x01) == 0x01;
case RomHeaderVersion.iNes:
return (_bytes[9] & 0x01) == 0x01;
default:
return false;
}
}
If my suggestion is included into the NES 2.0 spec, all old emulators which used similar code would work exactly as it was designed before. That's why this "legacy behavior" exists in my proposition. The thing that an emulator which doesn't support Dendy mode could use the fallback behavior is just a nice addition to the backward compatibility.
NewRisingSun wrote:
I am getting completely confused by your use of the term "preferred". Preferred by whom?
There is a preferred system which is selected in the ROM, there is another preferred system which may be selected by the user. rainwarrior has provided a description of behavior of an emulator:
rainwarrior wrote:
I think a useful set of user options to provide are: Auto (emulator chooses based on preference if supplied, otherwise arbitrary), Prefer X (user chooses system X, it is used if supported and no preference is supplied, otherwise same as Auto), Force (user chooses and the supplied options are ignored).
In other words: There is a list of supported systems by ROM, and a preferred system selected in the ROM. A user of an emulator can choose a preferred system in the settings of the emulator: Auto, NTSC, PAL, Dendy, Force NTSC, Force PAL, Force Dendy. If the user specified Auto (and it is the default behavior), emulator will always use the preferred system specified in the ROM itself. If the user chooses NTSC/PAL/Dendy as preferred, the emulator checks if the preferred system by user is supported by ROM, and if it is, it will use the preferred by user system. Otherwise, it will use preferred by ROM system. And if the user chooses to force NTSC/PAL/Dendy, the emulator just ignores the byte in the header and always used the forced system.
NewRisingSun wrote:
I think you mean to say "Dendy is correct, but the game can also run without serious glitches on NTSC/PAL as a second-best option". That might be less subjective, but we still have the problem that this information is more encyclopaedic than useful
If the ROM has specific code to work properly on all known systems (it
detects current system and makes some adjustments), it is not a useless information. Even in this case there could be just one the best option, because it is not possible to make exactly the same behavior on all the supported systems. Just not possible and that's it.
NewRisingSun wrote:
A user wants to run a game on an emulated console it was not made for? Who does that? Highly contrived, and does not justify adding a header field.
It is a normal use case. If you don't do it, it doesn't mean that nobody else does it. A lot of people played NTSC games on Dendy in their childhood. And sometimes they prefer to play these games with the same timings even nowadays, and they don't care that the games weren't designed for Dendy. I can say even more. Sometimes they buy a Famicom and modify it to use a chipset from a famiclone with Dendy timings, to play a Famicom with Dendy timings. That's why there should be a possibility to force any system, even when a ROM doesn't support it.
NewRisingSun wrote:
Highly contrived, and does not justify adding a header field.
It is not adding a new field, it is using an existing one.
VEG wrote:
This field is already supported by the emulators which know about NES 2.0. (...) It is not adding a new field, it is using an existing one.
"Additional field" refers to the added bits to byte 12, not the entire byte or NES 2.0 in general. Also, the Dendy bit as I proposed has already been implemented by Mesen and NintendulatorNRS, and ROMs have been distributed setting bits using that proposal. So for me, that is the "legacy behavior" to consider.
VEG wrote:
The thing that an emulator which doesn't support Dendy mode could use the fallback behavior is just a nice addition to the backward compatibility.
Again, accommodating emulators who don't want to add Dendy mode is not a legitimate goal for a header specification.
VEG wrote:
If the ROM has specific code to work properly on all known systems (it detects current system and makes some adjustments), it is not a useless information
I still fail to see the value. I don't care if a ROM adjusts itself or not --- I just want to play the game or demo properly, and that's it, and if I do want the emulator to replicate the console I had or have, I'll use the emulator's "region override" option, but then I will accept that the game may run with flaws, or not at all.
VEG wrote:
A lot of people played NTSC games on Dendy in their childhood. And sometimes they prefer to play these games with the same timings even nowadays, and they don't care that the games weren't designed for Dendy.
I read that as "I want to play the games like my childhood console, except where it's not possible, but only then I will accept something else". Seems possible, but still highly contrived, too contrived to warrant additional byte 12 bits.
NewRisingSun wrote:
Also, the Dendy bit as I proposed has already been implemented by Mesen and NintendulatorNRS
The issue that your proposition is poorly compatible with old code. For example, if I use an old version of Mesen with a ROM which uses 00000011 in this byte, it would always fallback to PAL, and it is wrong, because it should be NTSC. With current implementation I always have to specify NTSC in the header (even if I need Dendy), just because I'm quite sure that all emulators understand it, and it is questionable with your proposition. I want to be sure that my ROM will work as expected using any old emulator (people update emulators not so frequently), so I just won't use the new NES 2.0 feature because it may cause issues. For my project, Dendy is the most preferred system, and PAL is the least preferred system. That's why I specify NTSC, because it is in the middle.
NewRisingSun wrote:
, and ROMs have been distributed setting bits using that proposal. So for me, that is the "legacy behavior" to consider.
It is unlikely, if you take into account compatibility issues of current approach, and the fact that it wasn't included into the specification. If there are really such ROMs, they had too little of time for spreading around the world.
NewRisingSun wrote:
if I use an old version of Mesen with a ROM which uses 00000011 in this byte, it would always fallback to PAL, and it is wrong, because it should be NTSC.
Says who? It is true that it would be falling back to PAL rather than NTSC, but there is no reason to think that one is more correct than the other. That the Dendy is closer to the NTSC NES in terms of timing than the PAL NES as an abstract matter is irrelevant; what matters is whether a game that
requires Dendy timing is more likely to run correctly with NTSC or with PAL timing, and I can show you several games that need Dendy timing but also run under PAL but not NTSC. (In fact, I know of no game that
requires Dendy timing that
does work with NTSC better than PAL.) Your proposal falls back to NTSC, mine to PAL; but that does not make yours correct and mine wrong. So there is no compatibility advantage to your proposal once the incorrect assumption that the correct fallback for Dendy is NTSC is out of the way.
This lack of compatibility advantage, together with its questionable applications, the fact that it is difficult to understand what exactly "preferred" means, that it uses more precious header bits for little relevant information, and (and I agree that this should come last and least) that it goes against what has already been implemented, I continue to oppose this extended byte 12 proposal.
NewRisingSun wrote:
"Additional field" refers to the added bits to byte 12, not the entire byte or NES 2.0 in general.
BTW, "preferred" system is not a new thing in my proposition. Current specification (without your changes) specifies meaning of two bits, and it has information about preferred system:
Code:
00 - NTSC is supported and preferred.
01 - PAL is supported and preferred.
10 - Both supported, NTSC is preferred.
11 - Both supported, PAL is preferred.
The specification describes it in other words, but effectively it means what I have described above. As an example, Mesen had used the last bit to detect if PAL system is preferred for years, and breaking it is not a good thing to do. Your proposal just force people to avoid these new features of NES 2.0 which may cause unexpected behavior.
NES 2.0 is all about backward compatibility. That's why you should always take into account how an old emulator will behave when it encounters a new file with the new features used.
NewRisingSun wrote:
Says who? It is true that it would be falling back to PAL rather than NTSC, but there is no reason to think that one is more correct than the other.
My proposition adds an ability to choose a fallback system. So, an author of a ROM would have an ability to choose.
NewRisingSun wrote:
That the Dendy is closer to the NTSC NES in terms of timing than the PAL NES as an abstract matter is irrelevant;
It is very relevant. The probability that a Dendy ROM will work properly on an NTSC system is higher than on a PAL system, just because Dendy was designed to be as much compatible with NTSC games as possible with 50Hz framerate.
NewRisingSun wrote:
Your proposal falls back to NTSC, mine to PAL; but that does not make yours correct and mine wrong. So there is no compatibility advantage to your proposal once the incorrect assumption that the correct fallback for Dendy is NTSC is out of the way.
My proposal allows you to specify a fallback system. So, in case of my proposal it will be NTSC or PAL, not just NTSC.
VEG wrote:
The probability that a Dendy ROM will work properly on an NTSC system is higher than on a PAL system, just because Dendy was designed to be as much compatible with NTSC games as possible with 50Hz framerate.
As I said before --- a purely abstract argument; I offer actual games as counter-examples (帝国风暴 - Napoleon's War version 980340, 西天取经 II - Journey to the West, Dark Seed - 黑暗之蛊, 櫻桃小丸子, Education Computer 26-in-1, Arabic Study Cartridge (32-in-1), 2002 World Cup P.K., to name a few).
VEG wrote:
Mesen had used the last bit to detect if PAL system is preferred for years, and breaking it is not a good thing to do.
Only if one agrees that the preferred fallback, in the absence of a "fallback system", is NTSC, which I do not.
VEG wrote:
My proposition adds an ability to choose a fallback system. So, an author of a ROM would have an ability to choose.
I am not asking for a fallback system at all. An emulator should support Dendy if Dendy is required, and if it cannot, it is going to emulate the game incorrectly anyway, which is another reason why I do not buy the breaking-compatibility argument. So it is a waste of three bits to want to minimize the incorrectness of the emulation. And the tiny number of ROMs that adjust themselves to all three systems (apparently your demo and a few games from Ei-How Yang) do not need a fallback system for compatibility anyway, because they will run nicely, if not optimally, as NTSC or PAL.
Oh, I missed another thing:
VEG wrote:
The specification describes it in other words, but effectively it means what I have described above.
The actual specification
says nothing about preferences. It only says "B: When set, indicates this ROM works on both PAL and NTSC machines." It does not state that in the presence of the B bit (bit 1), the P bit (bit 0) would indicate a preference. That may be how earlier versions of Mesen interpreted it, but is not in the specification, and is not universal --- stock Nintendulator, for example, just ignores the P bit in the presence of the B bit, leaving whatever region was set before intact:
Code:
if ((RI.INES_Version == 2) && !(RI.INES2_TVMode & 0x02))
SetRegion((RI.INES2_TVMode & 0x01) ? REGION_PAL : REGION_NTSC);
It is with this interpretation in mind that I wrote my proposal.
NewRisingSun wrote:
And the tiny number of ROMs that adjust themselves to all three systems (apparently your demo and a few games from Ei-How Yang)
A lot of homebrews do similar adjustments. I took the idea of the adjustment of speed from Shiru, who made a lot of NES games, and his neslib (which makes this adjustment by default) is used by other authors of NES games.
NewRisingSun wrote:
I am not asking for a fallback system at all. An emulator should support Dendy if Dendy is required, and if it cannot, it is going to emulate the game incorrectly anyway.
Dendy is preferred, but NTSC could and should be used as a fallback. Don't try to diminish this use case. Be constructive.
Based on that last response, it seems that there is nothing more to add from you (and me). I continue to oppose it --- the fact that your compatibility-breaking argument turns out to be possibly true only for certain versions of certain emulators is an additional reason. And unless there is overwhelming support for it from others, I will not add it to NintendulatorNRS, for all the reasons already given.
What does need to be pointed out in the specification however is that the VT03+ famiclones have no such thing as "PAL" (2C07) timing: NTSC and PAL versions are the same chips which are just configured for a particular television system through solder pads (one of the pins is hilariously labeled "XPORN"), and by connecting the appropriate quartz oscillator. The "PAL" VT03+ configuration is equivalent to the Dendy-like timing.
All games for these consoles however are clearly developed for 60 Hz, as evidenced by the fact that the television-system-independent handheld consoles on which they also appear choose 60 Hz timing, so the proper region for these games will be NTSC anyway.
We had a discussion on the bootleg games Discord on whether it was possible to change the setting without exchanging the quartz oscillator. I would expect that one could get a usable, though not 100% standards-conforming signal, when using the oscillator it already has, such as the 26.6 MHz XTAL seen in your picture. According to the
VT02 application note, there are four different crystals, and only one of them would be correct for the four different television systems supported. (I am not sure about the specifics of the S model of the VT02 though.)
Also I'd like to discuss this part:
Code:
Byte 9: Upper bits of ROM size
7 0
---------
CCCC PPPP
C: 4 more CHR ROM size bits
P: 4 more PRG ROM size bits
If P/C has the value $F, header bytes $4/$5 changes meaning from number of 16 KiB/8 KiB PRG/CHR banks to the following floating-point-like format:
7 0
---------
EEEE EEMM
|||| ||++- Multiplier, actual value is MM*2+1 (1,3,5,7)
++++ ++--- Exponent (2^E), 0-63
The actual PRG- or CHR-ROM size therefore becomes 2^E * (MM*2+1). This allows for ROM sizes larger than the current maximum of 64 MiB without too much padding.
I believe that this change of meaning of $F should be removed completely. There are a lot of reasons:
1. It breaks compatibility with old specification which allowed $F.
2. So, it reduces the maximum effective size which is possible to specify if you want to keep compatibility with the de facto NES 2.0 specification. It reduces it twice.
3. It makes a complicated and tangled format even more complicated and tangled.
4. It is very approximate, you can't specify precise size.
5. None of the old emulators understand it. It is effectively the same as creation of an absolutely new header format. It makes no sense to imitate the structure of the iNES header in this case.
6. Actually, it is even worse. Old emulators will try to load it because it tries to imitate iNES format, and a file which uses the proposed change would look like a usual iNES file for them.
To handle the case when the ROM is so huge that the de facto NES 2.0 can't handle it, just increase the header size twice and put DWORDs for every value in question. To prevent old emulators from using this files with increased headers, and to distinguish files with default header size and with increased header size, just use NES 0x1B instead of NES 0x1A as a signature. It will prevent old software from loading this file with extended header size, because it would not be able to load it anyway.
Conclusion: we have 16 bytes in the default iNES header. It makes sense to add new fields which preserve compatibility with iNES, otherwise it does make no sense to keep ourselves in the window of 16 bytes. So, adding a field which describes which input device is preferred is a nice idea. If I specify this field, newer emulators would take advantage of it, older emulators would just work as before, everyone is happy. But changing format in a way which literally breaks everything makes no sense if you try to keep compatibility with iNES. Just increase the header size, make it intentionally incompatible by changing of the signature, and the problem is solved. Moreover, it will not introduce additional problems, because old software will understand that it don't know how to handle such files right from the beginning of reading a file, because of the signature.
Since I merely adopted this part based on
rainwarrior's proposal, I will let him handle this (if he chooses to).

I proposed it only for the sake of argument, really. Personally I don't even care about ROMs large enough for this field change proposal to be relevant, so please don't consider me a person who should be standing behind that idea, but that said I don't think any of those 6 points were valid.
VEG wrote:
1. It breaks compatibility with old specification which allowed $F without reasonable advantages.
2. So, it reduces the maximum effective size which is possible to specify if you want to keep compatibility with de facto NES 2.0 specification. It reduces it twice, without any good reason for it.
3. It makes a complicated and tangled format even more complicated and tangled, without good reasons for it.
4. It can't specify precise size.
5. None of the old emulators understand it. It is effectively the same as creation of an absolutely new header format. It makes no sense to imitate the structure of the iNES header in this case.
6. Actually, it is even worse, because it tries to imitate iNES format, old emulators will try to load it.
1. The old specification's $F was useless, as there are no ROMs of that specified size, and impossible to have a ROM of that size. ROM chips do not come in sizes like that.
2. No the exponent vastly increases the range of possible sizes. Please review what it actually does.
3. The practical reason was that the new size barrier the first iNES 2 draft created has already been broken by at least one homebrew.
4. Yes it can, there's no imprecision here. Again please review what it actually does.
5. No old emulator can run a ROM that's bigger than the format could specify, yes that's true. Why would they? There is no such thing as backward compatibility for that.
6. You can't make an old emulator forward compatible with a ROM that requires new features. That's not a reasonable goal.
rainwarrior wrote:
2. No the exponent vastly increases the range of possible sizes. Please review what it actually does.
I mentioned "if you want to keep compatibility with de facto NES 2.0 specification". It means that when different emulators (old and new ones) treat $F in different ways, it makes no sense to use such a value, if you care about compatibility of your ROM.
rainwarrior wrote:
4. Yes it can, there's no imprecision here. Again please review what it actually does.
OK, accept it. Probably, this idea is a good one for a new header format.
rainwarrior wrote:
3. The practical reason was that the new size barrier the first iNES 2 draft created has already been broken by at least one homebrew.
I meant that there is no any good reason to imitate iNES in this case. The result is effectively a new format.
rainwarrior wrote:
5. No old emulator can run a ROM that's bigger than the format could specify, yes that's true. Why would they? There is no such thing as backward compatibility for that.
6. You can't make an old emulator forward compatible with a ROM that requires new features. That's not a reasonable goal.
That's why it makes no sense to imitate iNES in this case. If a file which uses a new feature requires a new emulator, we should reliably prevent old emulators from trying to load these files (by changing the signature), and we can use any new format of the header in this case, without trying to look like an iNES file. We are not limited to these 16 bytes if we introduce something which is not compatible with old emulators at all.
I just want to say that if we introduce such changes, we could just create a new header with slightly different signature (like 0x1B instead of 0x1A) and with all the required fields without ugly hacks like a mapper number stored in different nibbles of 3 different bytes. So, this NES 0x1B even could use proposed by rainwarrior scheme of specifying of the size, but without storing 0xF in the byte 9 or somewhere else. What do you think? I don't see any good reason for sticking to the signature of iNES and trying to imitate this format in such cases.
Emulators that haven't implemented that different meaning for $F aren't treating $F in a different way, they're not treating $F at all. It's simply an invalid size for a ROM, and no such ROM will ever exist. There is no conflict of meaning for it.
The only practical sizes for PRG ROM or CHR ROM are 1, 3, and 5 times a power of 2.
- 1 * 2k represents 1 ROM or 2 of equal size (e.g. After Burner CHR).
- 3 * 2k represents 3 ROMs (e.g. Action 52 PRG) or 2 ROMs, the first twice as big as the second (many Super NES games).
- 5 * 2k usually represents 2 ROMs, the first four times as big as the second (many Super NES games including Mega Man X and Street Fighter II Turbo).
A ROM size leading with $F is none of these.
Also, hypothetically if there ever was a counterexample to this, for whatever insane reason, the only negative consequence is a small amount of padding (relative to the file size).
BTW the PowerPak ROM loader relies on only power of 2 sizes in these fields, because it constructs its bank bitmask as "size-1". That's actually a pretty reasonable implementation that will cover all but a small handful of ROMs which mostly couldn't run on the PowerPak anyway.
Guys, don't be so short-sighted. Nothing prevents anybody from creation of a custom cartridge with 64+8KiB of PRG ROM, for example. I provide this amount of ROM as an example because I considered creation of such a mapper for some special purposes just a few months ago.
And you argue with the least important point. The most important point is that it does not make any sense to imitate iNES header in this case. Introduction of such kludges have no any advantages over a completely new header format. Let's create a new proper header without these ugly hacks to cover situations which aren't covered by current NES 2.0 and can't be covered without breaking compatibility with old emulators.
You are not breaking compatibility with existing emulators: Along with the large ROM size must come a mapper that supports such large ROMs. An emulator not supporting the $F notation will also not support such mappers. When loading such a ROM, it will merely print "Mapper
#342 not supported" and quit, not caring about the ROM size at all. A completely new NES header would instead produce a message such as "not a NES file" or "invalid file", which is much more confusing to the user. In the worst case, the old emulator compares the file size against the header ROM size before looking at the mapper number, and it would then complain about an unexpected end of file, which is no worse than getting "not a NES file".
Also, there already was a now-deprecrated iNES replacement that had DWORD size specifiers, called
UNIF. One of the reasons for its deprecation was lack of popularity. That problem will be even greater here: nobody is going to support a new format just for a few large-size homebrew and pirate ROMs, but they might support an extension to an existing format plus one or two new mappers.
Yeah, let's make the messy NES 2.0 header format even more messier. More kludges, more hacks, more ugliness. For the sake of chaos and increasing of entropy.
Let's get back to the TV System byte, because it is the extension which would be really useful if added to the iNES, NES2.0 and UNIF formats.
Just a reminder of the proposition:
Code:
Byte 12 in NES 2.0 (or Byte 9 in iNES, or TVCI byte in UNIF):
7 0
---------
xdpn xxBP
The byte consists of two nibbles. The higher nibble describes which systems are supported, the lower nibble describes which system is preferred.
If higher nibble is 0, use legacy interpretation:
0000 0000 - NTSC only
0000 0001 - PAL only
0000 0010 - Supports NTSC and PAL, but NTSC is preferred
0000 0011 - Supports NTSC and PAL, but PAL is preferred
Otherwise, higher nibble describes supported systems:
d - Dendy
p - PAL
n - NTSC
Lower nibble (bits BP) describes preferred system:
00 - NTSC (a legacy emulator will use NTSC)
01 - PAL (a legacy emulator will use PAL)
10 - Dendy with fallback to NTSC (a legacy emulator will use NTSC)
11 - Dendy with fallback to PAL (a legacy emulator will use PAL), or just reserved
If the lower nibble chooses the system which is not marked as a supported system in the higher nibble, fallback to the legacy behavior. Bits 2,3 and 7 should be ignored by emulators, and should be 0 in ROMs.
Similar fields
are already available in the NSFe format in the regn section. It would be nice to have the same ability in NES format also.
There is a list of supported systems by a ROM, and a preferred system selected in the ROM. A user of an emulator can choose a preferred system in the settings of the emulator: Auto, NTSC, PAL, Dendy, Force NTSC, Force PAL, Force Dendy. If Auto is specified, emulator will always use the preferred system specified in the ROM itself. If the user chooses NTSC/PAL/Dendy as preferred, the emulator checks if the preferred by user system is supported by the ROM, and if it is, it should use the preferred by user system. Otherwise, it should use preferred by ROM system. And if the user chooses to force NTSC/PAL/Dendy, the emulator just ignores the byte in the header and always uses the forced system.
I know that NewRisingSun don't like this proposal, he has
an own one which extends the same byte in a different way. This comment is an invite for others to state their opinions about such an extension.
VEG wrote:
Nothing prevents anybody from creation of a custom cartridge with 64+8KiB of PRG ROM, for example. I provide this amount of ROM as an example because I considered creation of such a mapper for some special purposes just a few months ago.
There are a lot of things preventing this. The primary thing is that it would be cheaper and easier to build a 128K cartridge than a 64+8 cartridge. You're making an argument based on a thing that is more or less absurd to make, and nobody is going to.
...and even if you DID build such a cart, you wouldn't need to use the extended bits anyway. It would just be listed as an 80k cartridge with the regular iNES 1 PRG size field, and there'd be 8k of padding. The point of the iNES 2 field (with or without the special $F proposal) is to extend the range of representable sizes, not accommodate pathologically hypothetical ROM sizes that fall in between the useful ones.
Quote:
Just a reminder of the proposition:
There is no need to duplicate that large block again here.
I think than VEG's proposal is better.
The same data (list of supported and a preferred system) is already available in the NSFe format.
So, it will be a feature parity between at least NSFe and NES 2.0
I have created a dedicated topic about it, with some additional details:
viewtopic.php?f=3&t=18060I hope that it will help to involve other people into the discussion.
NewRisingSun wrote:
Also, there already was a now-deprecrated iNES replacement that had DWORD size specifiers, called
UNIF. One of the reasons for its deprecation was lack of popularity. That problem will be even greater here: nobody is going to support a new format just for a few large-size homebrew and pirate ROMs, but they might support an extension to an existing format plus one or two new mappers.
First of all, UNIF is supported by popular emulators. And I see no any reasons to remove its support. Second, it is not a mere header, it is much more complex. This format is an overkill for most cases, that's why it is not wide adopted. But it is used on special cases. For example, COOLGIRL multicarts use it, and UNIF really suits better this rare case.
Regarding the exponent * multiplier way of determining ROM size, I think this is how it works :
Galaxian 8KB PRG-ROM = 2^13 * 1 = #00110100 = $34
Here are some non-power of 2 PRG-ROM sizes I know of that can be represented by this system :
Vs. Tetris 24 = 2^13 * 3
Vs. Gumshoe 40 = 2^13 * 5
Vs. Raid on Bungeling Bay 40 = 2^13 * 5
Vs. Mahjong 48 = 2^14 * 3
Pegasus 5 in 1 1280 = 2^18 * 5
Action 52 1536 = 2^19 * 3
I can't get it to work for these PRG-ROM sizes, but fortunately they are encompassed within a single submapper :
Nantettatte!! Baseball Ko-Game Set '91 Kaimakuban 144
Nantettatte!! Baseball OB All Star Hen 144
For 144 KiB, you just denote 9 16 KiB banks. The exponent-multiplier system is only used for sizes that could not be expressed before.
NewRisingSun wrote:
For 144 KiB, you just denote 9 16 KiB banks. The exponent-multiplier system is only used for sizes that could not be expressed before.
I was trying to get the number using the exponent-multiplier system, but it only went up to seven. I forgot that original system is 16K * 2^(Byte 4).
I am pleased we can finally express Galaxian's 8KB in an understandable format. Now everyone just needs to shut up and embrace the future of NES ROM identification

In hindsight, having the table be {1,3,5,9} would make more sense than {1,3,5,7} — you can only get 7 by having three ROMs — but I really don't care enough to do anything more than point this out.
How I love it when people care enough to post how much they don't care.

Great Hierophant wrote:
I forgot that original system is 16K * 2^(Byte 4).
No, the original iNES system is just 16K *(Byte 4), and with NES 2.0, 16K * (Byte 4 OR ((Byte 9 AND $0F) SHL 8)).
For the controller byte, would it be a good idea to use the high bit to distinguish between games where the controller is required versus games where it is optional? That still gives you 128 possibilities for controller assignments. The idea is to allow emulators to notify the player of an option and ask if they'd like to use it.
I have observed how Nestopia "emulates" R.O.B. It only emulates a portion of R.O.B.'s functionality, namely using the start button to send commands allows buttons A and B on controller two to remain pushed down. Ideally, for either game R.O.B. would be emulated in a second window, where you could see the robot do its thing and his hands and the gyros would be animated. But for Stack-Up, R.O.B. could be easily simulated by writing a little puzzle application in which you can use a cursor to move colored "blocks" in the way R.O.B. can, from the bottom Block you select. R.O.B. has no trouble moving all five Blocks in reality as shown in Jeremy Parish's videos. For U-Force, I think you might be able to get away with using a Wiimote, but for the Power Glove you would need something like a Kinect because the Glove can recognize finger movements. Emulators will ultimately only recognize what they can support.
Also, for Smash TV, I noted that both the NES Satellite/Four Score or the Double-Fisted categories apply to the game, but NES 2.0 only allows you to select one option. I would suggest ditching the double fisted option for this game because the game allows you to use one or two controllers to control each character and clearly indicates it in the game options menu. Crazy Climber requires Double-Fisted control, but it may not be instantly obvious on running the game.
The TV System byte, if strictly enforced, could lead to revisiting most of the "black box" games' ROM headers, as they typically did have PAL-optimized releases. ROMs with the (World) or (USA, Europe) designations would be eligible for designation.
I agree that a Kinect sensor would be closer to ideal for the Power Glove, as it senses the position of the hand rather than its direction. However, I'd wager that mapping the thumb to the Wii Remote's A button and the other fingers to B should allow existing Glove-aware software to run.
I have now rewritten the
wiki NES 2.0 page for brevity and added the content of this proposal, hopefully incorporating all points that were made and agreed-upon. Thanks to everybody who participated in the discussion!
Great Hierophant wrote:
I have observed how Nestopia "emulates" R.O.B. It only emulates a portion of R.O.B.'s functionality, namely using the start button to send commands allows buttons A and B on controller two to remain pushed down. Ideally, for either game R.O.B. would be emulated in a second window, where you could see the robot do its thing and his hands and the gyros would be animated. But for Stack-Up, R.O.B. could be easily simulated by writing a little puzzle application in which you can use a cursor to move colored "blocks" in the way R.O.B. can, from the bottom Block you select. R.O.B. has no trouble moving all five Blocks in reality as shown in Jeremy Parish's videos. For U-Force, I think you might be able to get away with using a Wiimote, but for the Power Glove you would need something like a Kinect because the Glove can recognize finger movements. Emulators will ultimately only recognize what they can support.
For Gyromite and Stack-Up, try
Nintaco. It also supports the U-Force.
NewRisingSun wrote:
I have now rewritten the
wiki NES 2.0 page for brevity and added the content of this proposal, hopefully incorporating all points that were made and agreed-upon. Thanks to everybody who participated in the discussion!
Thanks for spearheading these changes. Some of the stuff below is based on our PMs.
Regarding VS Hardware type, can the header specify the exact VS game? Currently, I see RBI Baseball, TKO Boxing, Super Xevious, Ice Climber, and Raid on Bungeling Bay listed there. And there aren't that many VS titles. Since the DIP switch settings are not specified in the header, the emulator will need to figure out which VS game it is anyway (through some other checksum means).
This may have come up earlier in the thread (I have yet to read through it entirely), but the Default Expansion Device list seems incomplete. E.g. if the default is R.O.B., is that R.O.B. setup for Gyromite or Stack-Up? For the Zapper, which is the default port? I also see U-Force is not listed. The prototype game does tap into it's analog abilities, suggesting that it should be on the list. If there is an option for 2 SNES controllers, why not toss the SNES mouse into the mix as well.
zeroone wrote:
can the header specify the exact VS game?
No, and I don't see why it should. It's only designed to specify PPU type and other protection, which not all games use. If you care about DIP Switches, that is not something for the Vs. Type field, as non-Vs. games can have DIP Switches as well.
zeroone wrote:
E.g. if the default is R.O.B., is that R.O.B. setup for Gyromite or Stack-Up?
Gyromite. I only added it because Nestopia can be made to press the 2P controller buttons like R.O.B. would. As discussed a few pages earlier, Stack-Up's blocks are not really something suitable for an emulator, unless you want to create a three-dimensional display of multi-colored blocks.
zeroone wrote:
Zapper, which is the default port?
Famicom expansion port, which translates to 2P on NES.
zeroone wrote:
I also see U-Force is not listed.
I have added it.
If you're doing Dualsystem, then you have to have two views anyway. The same is true of Wide Boy with Game Link. I guess the "three-dimensional display of multi-colored blocks" could appear in the second view for a R.O.B. game.
NewRisingSun wrote:
Gyromite. I only added it because Nestopia can be made to press the 2P controller buttons like R.O.B. would. As discussed a few pages earlier, Stack-Up's blocks are not really something suitable for an emulator, unless you want to create a three-dimensional display of multi-colored blocks.
Nintaco already renders R.O.B. in a separate window. And that view is different for Gyromite and Stack-Up. In fact, for Stack-Up, the player normally hits Start after completing the block arrangement (it's the honor system). But Nintaco monitors the game state by peering into CPU RAM and it triggers Start automatically at that time (as if R.O.B can see what you're doing).
Specification of the R.O.B. configuration is far more valuable than just "plug in R.O.B.".
tepples wrote:
If you're doing Dualsystem, then you have to have two views anyway. The same is true of Wide Boy with Game Link. I guess the "three-dimensional display of multi-colored blocks" could appear in the second view for a R.O.B. game.
Nintaco uses 2 views for things other than R.O.B. such as the 3D glasses. I'm still thinking about the best way to present the VS DualSystem, if I ever get that working. I'd much rather prefer that to be a Netplay exclusive where each emulator was the view.
I just looked up the Wide Boy. I had no idea that existed. Since the NES is only used as a pass-through device, it sounds a bit ridiculous to emulator/simulate that for an NES emulator.
NewRisingSun wrote:
No, and I don't see why it should. It's only designed to specify PPU type and other protection, which not all games use. If you care about DIP Switches, that is not something for the Vs. Type field, as non-Vs. games can have DIP Switches as well.
I understand. But it's unfortunate that a Cart DB will still be required even with this new header system. As soon as extra cart data needs to be stored in a table within the emulator anyway, all the other stuff in the header can be stored along with it. Unless the header really contained 100% of the data required to run the game properly, the Cart DB is going to be the preferred authority. Of course, if a particular game is not in the Cart DB, the more data available in the header the better.
I do not accept that you need DIP switch documentation to run a game properly. All games that I am aware of can absolutely be played properly even if you don't know what every DIP switch setting means. Without a database, depending on the Console Type/Mapper PCB that defines whether there are DIP switches at all, you could present the user with unlabelled DIP switch controls, as many emulators already do. I do not quite see the difference between labelling DIP switch controls and, say, labelling memory locations, for cheating or any other purpose. Surely nobody would ask to include labels for memory locations in a ROM image file! Therefore, I consider DIP switch documentation non-essential, while Mapper variant or default expansion device information are essential, for playing a game.
zeroone wrote:
As soon as extra cart data needs to be stored in a table within the emulator anyway, all the other stuff in the header can be stored along with it.
It could, but why should it?
That being said, I am not opposed
in principle to including DIP Switch labels in a .NES file. I just consider it impractical, no,
impossible to do so while keeping the entirety of a .NES file unambiguous, so that DAT projects such as No-Intro can start indexing complete .NES files including headers. Text
fields are inherently subjective, with different punctuation, spacing, capitalization, romanization all encoding the same information correctly yet differently. I have seen this with NSF files --- the exact same file exists in up to three different variations, differing in the title/author/copyright fields alone, without any one of them being "incorrect".
zeroone wrote:
Specification of the R.O.B. configuration is far more valuable than just "plug in R.O.B.".
It does not say "plug in R.O.B.", it says "R.O.B. Gyro set". An entry for "R.O.B. Stack-Up" could be added, but I would have to see what such an emulation would look like.
After seeing how Mesen has implemented, I have a request for Byte 15:
Add a value for "do not override user settings" or something of that nature. This is needed for stuff like tepples' "allpads" or other situations where it's deliberately wanted for the user to plug in what they like.
The current default for Mesen is to basically stomp on all custom input settings if there is an iNES 2.0 header, because "00" was used to mean standard controllers, and this seems more like an unfortunate consequence of this specification, rather than a bug in Mesen, like that really seems what the emulator should do according to the spec.
Wish this value could have been $00, but I hadn't noticed this consequence until seeing it in action now.

In general adding anything new to the iNES 2 spec where $00 introduces a
new behaviour is not good, IMO. Feels like an accident that this spec results in new behaviour, but I think it does manifest that way.
I had originally called value $00 "unspecified, use standard controllers", assuming that an emulator will default to standard controllers when loading a ROM without any information on the expected input device, having observed that Nestopia (I think) does that if it cannot find a ROM in its internal database. That is why I defined no separate values for "unspecified" and "standard controllers". I am not quite convinced that this should be changed --- whoever selects an input device before loading a ROM? For "allpads", I would load the ROM, causing the emulator to default to standard controllers, then for every device that I want to test with "allpads", select it from the emulator's menu (which the spec explicitly calls for to be possible), then Soft-Reset. So I am not sure what an allpads setting would do, or why standard controllers needs to be separate from unspecified.
I would suggest the definition be more open, something closer to just "no information about controllers", and leave it at that. $00 should explicitly mean that the author either doesn't know or hasn't filled in this field; all older iNES 2 ROMs are already leaving $00 here because it was reserved.
Using standard controllers, or assuming user input is consequential behaviour from there being no information, but what should be done really depends on the emulator author's goals etc. I think, shouldn't have to be called out in the spec.
Allpads is tepples' input emulator test ROM:
https://wiki.nesdev.com/w/index.php/Emulator_tests#Input_TestsThe point of that ROM is to figure out what you have connected. Obviously this ROM would never want to specify which controllers to use. This is the most extreme counterexample of why $00 implying standard controllers is bad, but this will more weakly also be a problem for any homebrew game that wanted special controllers and was using iNES 2 header before this was specified.
Otherwise I do think it would actually be good to have an explicit specification for "standard controllers" too, and probably that would be the one we should use most often, since that's what most games need, but if e.g. that option was $01 it would mean "this game is known to require standard controllers" and $00 would mean "no information about controllers".
"Standard controllers" cannot be $01 unless everything else moves down one number. Some recent ROM images already use that field, and I do not want to invalidate or replace them.
I actually have no problem at all with value $00 having a definite interpretation in NES 2.0, and the Default Expansion Device field is not alone in that regard: a NES 2.0 PRG/CHR-RAM value of $00 definitely causes a difference compared to iNES, as anybody who has ever naively converted an UNROM game can attest. The same goes for the TV System byte. In fact, I cannot think of any other NES 2.0 field where value $00 really means "no information", and in my stated interest of avoiding ambiguity, I don't really want to introduce one. (That's why I now take back the word "unspecified" that is not on the wiki, but was part of the draft earlier in this thread.)
Defining "$00" as standard controllers would only invalidate ROMs that already are NES 2.0 but were released as such before the specification update and need something other than standard controllers. The vast majority of NES ROMs are iNES, and most of the few NES 2.0 ROMs that have been released would not have set this field to anything other than $00 Standard Controllers anyway. On the other hand, defining Standard Controllers as anything other than $00, and defining $00 as "no information" would mean that the majority of released NES 2.0 ROMs would become underspecified with one stroke.
So therefore, I continue to oppose defining value $00 as anything other than standard controllers. I will gladly add a device value for "allpads", though I would want a better description than "do not override user settings", more like a generic description of what it is instead of specific instructions on the consequences that the emulator should take. "Any"?
rainwarrior wrote:
After seeing how Mesen has implemented, I have a request for Byte 15:
Add a value for "do not override user settings" or something of that nature. This is needed for stuff like tepples' "allpads" or other situations where it's deliberately wanted for the user to plug in what they like.
FYI, you can disable byte 15's behavior by disabling the "Automatically configure controllers when loading a game" option in the input options. This disables using both the game database and byte 15 to select controllers.
The test screen you see depends on the type of controller you connect. It's not unlike the situation with Super Mario Bros./Duck Hunt/World Class Track Meet. So would the definition of "multicart" fit?
No. "Multicart" signals that different expansion port devices are required depending on which game was selected. Ideally, the expansion port device automatically changes (endogenously) as the PRG-ROM mapped into CPU address space changes through (exogenous) user action, though how to account for that is up to the emulator.
Since the expansion-port-using games on common multicarts usually are the Zapper games, the spec recommends emulating an expansion port Zapper plus two standard controllers as the simplest way to account for that, though more involved approaches are possible, such as checking for the port-reading signatures of the handful of common multicart games, which is what I do in NintendulatorNRS, and turns out to be very ROM-hack-robust.
Allpads, as I understand it, is the opposite --- the PRG-ROM mapped into CPU address space is always the same, but takes different code paths (endogenously) as a result of (exogenous) changes in the connected expansion port device.
NewRisingSun wrote:
No. "Multicart" signals that different expansion port devices are required depending on which game was selected.
From a certain point of view, if you pretend each test screen is a "game", and a game is "selected" by plugging in the correct controller and pressing its primary button... But I admit it's a stretch and a bit backward in a way from the usual use of the term.
NewRisingSun wrote:
On the other hand, defining Standard Controllers as anything other than $00, and defining $00 as "no information" would mean that the majority of released NES 2.0 ROMs would become underspecified with one stroke.
iNES 2.0 has been around for quite a few years now and there are quite a lot of ROMs out there using it. I don't even know where to begin enumerating these. The spec for controllers is only
9 days old. I think you're vastly underestimating what might be invalidated by changing the meaning of $00 (which was until that point specified as reserved). You're making the assumption that everything people have done with this header for
years needs to specify standard controllers. Allpads is not at all the only example, just the very clearest one to demonstrate the need.
They're not "underspecified", they are specified with exactly as much information as the author gave them, and it is simply wrong to assume that anyone meant specifically standard controllers before it was part of the spec.
I know you have some idea that you want to be able to say there is one canonical header for every single ROM out there, but there's a difference between being able to suggest one "best" header and insisting that every possible piece of data always has to be specified. This is an
optional field, and it has to be because of its historical use. All of the later additions like this have to be. iNES 2.0 has legacy already.
I strongly oppose insisting that old ROMs get new meaning imposed on them by the change to this field. Reserved $00 meant
reserved, not "you have to come and change this later when someone feels like changing the format".
NewRisingSun wrote:
The same goes for the TV System byte In fact, I cannot think of any other NES 2.0 field where value $00 really means "no information", and in my stated interest of avoiding ambiguity, I don't really want to introduce one. (That's why I now take back the word "unspecified" that is not on the wiki, but was part of the draft earlier in this thread.)
Byte 15 was defined as "reserved as $00" since the beginning of iNES 2.0 as a proposal and until 9 days ago. Every single other byte of iNES 2.0 had a defined value for $00 since its inception, and/or subsequent additions to it haven't changed the meaning. TV system is not comparable, as it was in iNES 2.0 since its
beginning in 2006.
NewRisingSun wrote:
"Standard controllers" cannot be $01 unless everything else moves down one number. Some recent ROM images already use that field, and I do not want to invalidate or replace them.
I don't really care what number you want to use for it, as long as it isn't $00. I said $01 just to make an example (though I think it'll be a little goofy it ends up as some random value because of this). How many recent ROM images have started using it in the last 9 days? Did you go and create a whole catalogue immediately after revising the spec? If you want to reorganize it or not I don't really care, all I really care about is the meaning of $00 here.
The suggestion that any other value could specify standard controllers is a concession for your goal to be able to recommend a fully specified header for everything under the sun. I've said before, I don't mind that goal, and I'm sympathetic to it, but I think it's unreasonable to insist that anything less than this is an invalid header. You can absolutely say that "this header that specifies $01 in byte 15 for game X that is known to require controller Y is better than specifying $00 in that byte", but you
cannot retroactively invalidate or change the meaning of $00 for it. Headers that do not specify controllers are valid. The meaning has to stay "unspecified".
I do actually love that you added this field to the spec. I thought for a long time this was needed, and it's a great option to have, but $00 needs to be backward compatible with the prior definition.
Sour wrote:
rainwarrior wrote:
After seeing how Mesen has implemented, I have a request for Byte 15:
Add a value for "do not override user settings" or something of that nature. This is needed for stuff like tepples' "allpads" or other situations where it's deliberately wanted for the user to plug in what they like.
FYI, you can disable byte 15's behavior by disabling the "Automatically configure controllers when loading a game" option in the input options. This disables using both the game database and byte 15 to select controllers.
Yes I did find the off switch for it, but I'd much rather be able to have this feature on without it disrupting ROMs that have been a casualty of this meaning change. I don't think that's possible with the definition NewRisingSun made for $00.
rainwarrior wrote:
I think you're vastly underestimating what might be invalidated by changing the meaning of $00
Then tell me. Which games were released in NES 2.0 format that do
require something other than standard controllers? I am willing to be persuaded by the number of games that will be invalidated, not by the vague theoretical possibility ("might").
Also, I question the use of "invalidated" --- before the field was defined, emulators would not choose the required input device for them (some even reverted to standard controllers for every newly-loaded ROM), so they would have to do it themselves. Now, it chooses the wrong one for them (standard controllers) so they have to do it themselves, after loading the ROM file, that is. The difference is that with $00 defined as standard controller, these ROMs would suffer the indignity of being "wrong", whereas if $00 is defined as "unspecified", they would be a more dignified "suboptimal"; but in both cases, the canonical header would be a different one. So I am not seeing any actual damage being done by giving value $00 a defined meaning, and do see actual damage by defining a format such that there are "optimal" and "suboptimal" headers, as opposed to simply correct and incorrect ones.
rainwarrior wrote:
They're not "underspecified", they are specified with exactly as much information as the author gave them
They were not underspecified according to the previous definition, but would be underspecified (or "suboptimal" if you prefer that term) according to
the updated one. your proposed one.
NewRisingSun wrote:
rainwarrior wrote:
I think you're vastly underestimating what might be invalidated by changing the meaning of $00
Then tell me. Which games were released in NES 2.0 format that do
require something other than standard controllers? I am willing to be persuaded by the number of games that will be invalidated, not by the vague theoretical possibility ("might").
Well you must understand that this is an extremely difficult question to answer. The iNES 2 spec has been floating around for more than a decade, though maybe it's only got traction in the last 5 years. Offhand I can think of a few homebrew to check but I think it would literally take me months to research this adequately.
What ROMs have been
created in the last 9 days that have $00 in there that you think are going to be invalidated, on the other hand should be extremely easy to answer, relatively speaking, shouldn't it?
What I'm asking for is to proceed with caution and not assume you can change meanings that have existed for a long time already. Someone who was using the iNES 2.0 spec from a month ago should be able to remain confident that they haven't had their work broken by a future change. Byte 15 was "reserved" and that does in fact mean exactly that they were not specifying anything in this byte.
NewRisingSun wrote:
Also, I question the use of "invalidated" --- before the field was defined, emulators would not choose the required input device for them, so they would do it themselves. Now, it chooses the wrong one for them (standard controllers) so they have to do it themselves. The difference is that with $00 defined as standard controller, these old ROMs would just be "wrong", whereas if $00 is defined as "unspecified", they would be "suboptimal"; in both cases, the canonical header would be a different one. So I am not seeing any actual damage being done by giving value $00 a defined meaning, and do see actual damage by defining a format such that there are "optimal" and "suboptimal" headers, as opposed to simply correct and incorrect ones.
I
am seeing damage done by it, which is why it came up. I think Mesen's interpretation and implementation of it is exactly what the current spec you wrote is calling for: $00 is telling the emulator that standard controllers has been specified, and it should override user settings, exactly like all the other values of this field should do with their respective control sets.
The value of $00 must not insist that the author was specifying for standard controllers, "no specification" is the only possible meaning that has backward compatibility with older versions of the spec.
missed one question:
rainwarrior wrote:
How many recent ROM images have started using it in the last 9 days? Did you go and create a whole catalogue immediately after revising the spec?
There have been ROM images released using it since Mesen added it based on the proposal. That was about six months ago or so.
rainwarrior wrote:
$00 is telling the emulator that standard controllers has been specified, and it should override user settings,
Only the
previous settings. I explicitly called in the spec for accepting user-defined settings after the ROM has been loaded. So again, I question the use of terms like "having their work broken". I may need to re-check what Mesen actually does, but if it
refuses to allow the user to choose something other than what the header calls for,
then I would agree with you that this is not what is supposed to happen.
rainwarrior wrote:
What I'm asking for is to proceed with caution and not assume you can change meanings that have existed for a long time already.
And what I am asking for is weighing the actual consequences, not the theoretical consequences, of either approach.
rainwarrior wrote:
How many recent ROM images have started using it in the last 9 days? Did you go and create a whole catalogue immediately after revising the spec?
The current release of Project Plug'n Play, which mostly consisted of reheadered ROMs that were released previously, has 569
ROMs .7z files, each of which containing one or several ROM files, and is dated January 2nd. There are also others going back six months, as mentioned, but you might say they don't count having been released before the spec was finalized.
NewRisingSun wrote:
missed one question:
rainwarrior wrote:
How many recent ROM images have started using it in the last 9 days? Did you go and create a whole catalogue immediately after revising the spec?
There have been ROM images released using it since Mesen added it based on the proposal. That was about six months ago or so.
So what are these ROMs? Were they published somewhere? Are they well known an accessible? Updateable? Changeable? Is this something you could automatically just replace $00 with $42 or whatever value you want to use to say "standard controllers specified"? (Presumably all other values are fine to keep, I'm only talking about $00.)
What you're try to weigh this against is a huge unknown, a spec we've been living with for many years... I could only begin to list stuff, but let's start with allpads and thwaite.
And I think we're weighing the new ROMs you're referring to being "underspecified" against some unknown number of homebrew from the past several years being specified wrongly. The underspecified thing I think is a lot less of a problem than assuming a ROM specifies something it doesn't. Giving the user the wrong set of controls is exactly what this byte should be design to
avoid.
NewRisingSun wrote:
rainwarrior wrote:
$00 is telling the emulator that standard controllers has been specified, and it should override user settings,
Only the
previous settings. I explicitly called in the spec for accepting user-defined settings after the ROM has been loaded.
That's not what it means. Yes of course an emulator should have an option to override any header information that is undesired, TV system, controls, etc. that really doesn't even need to be mentioned in the header spec, IMO.
The problem is if the ROM says "X is specified", the automated selection is allowed to apply. It should
never apply if something is unspecified.
...and that's exactly what Mesen is doing. It's applying it because it thinks $00 is specified... which it isn't. A user should be able to have this option on without it breaking ROMs that were made before the change.
It's also not just about ROMs that exist, this can affect any homebrewer that is working from an older version of the spec. People should be realistically be able to make valid iNES 2 ROMs with what the wiki said 1 months ago. I have published a bunch of example code or open source stuff that says "reserved" in the comments for this byte, etc. we can't insist that everyone is suddenly up to date with the current spec always.
I'm sure tepples' has some open source code lying around on websites, for example. If someone uses thwaite's source code as an example to build on, there are 4 different versions of that source out there, available in different places, many of which tepples could not reasonably update, all of them currently "wrongly" specifying standard controllers by this change, it would seem?
I don't know who published ROMs using a new spec 6 months ahead of when you made it public on the wiki, but when moving forward the lag in information propagation will be huge.
rainwarrior wrote:
So what are these ROMs?
Answered
above.
rainwarrior wrote:
What you're try to weigh this against is a huge unknown. (..) I could only begin to list stuff, but let's start with allpads and thwaite.
Well, list some more, because so far, the huge unknown consists of two ROMs, one of which is not a game.
What really irks me right now is that the proposal
and Mesen's interpretation of it have been
out there for
half a year. Some people have contributed to it (including you, though not to that field), not without feeling the need to express how much they actually don't care but are just sayin' and stuff, and now that it has been finalized the way it was proposed, now that a sizable number of ROMs (see my previous post) have been (re-)released,
now somebody suddenly has concerns that the most common field value is unacceptable because it breaks two ROMs and a "huge unknown", except that it does not actually break them but just requires the same user intervention it previously did. What do you expect me to say?

Every single ROM I have ever released has had NES2.0 headers and has left that byte as its "reserved" value. Automatically switching to "standard controllers" is wrong for at least 3/4 of them. Are most of them not games? Yes. Does that matter? No.
Demanding that you be enumerated every single thing that it breaks is unfair to everyone else. How can we track it down? How can anyone? That's the entire point of leaving the standard as upwards compatible.
On the other hand, you know exactly what ROMs you've released with a 0 in there meaning "override the emulator's settings with standard controllers".
lidnariq wrote:
Demanding that you be enumerated every single thing that it breaks is unfair to everyone else.
I did not demand that. I asked for something more specific than a "huge unknown". Mostly, I "demanded" that you should have said something in the past six months when the proposal was out there, instead of going out of your way to declare how much you don't care.
And I already described how the "breaking" aspect is pretty much of a nothingburger.
NewRisingSun wrote:
rainwarrior wrote:
So what are these ROMs?
Answered
above.
That wasn't just a single question:
rainwarrior wrote:
Were they published somewhere? Are they well known an accessible? Updateable? Changeable? Is this something you could automatically just replace $00 with $42 or whatever value you want to use to say "standard controllers specified"? (Presumably all other values are fine to keep, I'm only talking about $00.)
Are the ROMs you're referring to are a romset that is updated periodically?
The point of this field is so that when you start up a ROM, the emulator will be able to provide you with the right control set automatically.
This change you made means anything made before the spec that wanted something other than standard controls
will get the wrong control set.
However, for any of these ROMs that were released based on the new spec, all it means is the ones that were specifying standard controls would now fall back to not specifying, which is a very mild consequence IMO and not even "wrong" controls but just whatever the underlying emulator default is (probably user settings).
NewRisingSun wrote:
What really irks me right now is that the proposal and Mesen's interpretation of it has been out there for half a year.
Well, I'm sorry I didn't catch it sooner. I noticed the problem just now, 9 days after you published the spec. I reported it as soon as I noticed it. I'd actually been having the problem with Mesen for a few months, I think, but I didn't realize that this was a consequence of that thing until today. I had no idea Mesen had implemented it proactively. Mesen is not the only emulator I use, either, so it took some luck that I just happened to be trying to write a game with mouse controls lately... which I started writing before this spec was published... and am now realizing that this problem with Mesen resetting its controls is more or less directly mandated by the spec you published.
NewRisingSun wrote:
rainwarrior wrote:
What you're try to weigh this against is a huge unknown. (..) I could only begin to list stuff, but let's start with allpads and thwaite.
Well, list some more, because so far, the huge unknown consists of two ROMs, one of which is not a game.
So... I can't speak for all the people out there working from older versions of the spec. There are a lot of people making homebrew NES games right now. Many of them will be in the dark about this change for a good long time. I would look at a bunch of the games on Action 53, there are at least 10 mouse and zapper games in there, some of which will have used iNES 2, some probably not. Many of them are open source releases, and have been public for many years, disseminating widely. That source code itself is more collateral, because it will teach new devs what to do as well, and that's all based on the older spec.
These are in a thousand different places in many forms. A lot of them have several versions of the ROMs in forum threads, versions of the source on various github pages, websites, etc. it's actually more or less impossible to update these retroactively.
...and ALL I'm asking for is for you to change the meaning for just $00 back to what it was, for backward compatibility with
all previous versions of the iNES 2 spec.
Yes, it downgrades that ROM release you were talking about, I guess, but it's a very, very small downgrade to fix a compatibility problem this redefinition of $00 created.
All right. That field has given me more trouble than anything else in there, and the prevailing opinion had been that it should not be there anyway, because description of what's inside the cartridge shells and such, so I am now disavowing it and removing it. Should anybody care to want it back, he can always choose an older version from the wiki and change it in a way that is satisfactory to him and the huge unknown. I shall have no opinion on it.
I
like the field. I think it's a very good addition. I only dislike the meaning you chose for $00.
NewRisingSun wrote:
the "breaking" aspect is pretty much of a nothingburger.
I don't want to make this an argument of sides where we're trying to argue one pile of ROMs to update is bigger than the other. That's not what I'm trying to do here, I genuinely feel that $00 specifying standard controllers hurts the spec.
In my view even if this were just about thwaite, the trade looks like this to me:
A. A bunch of well known games need to specify that they use the standard controllers 6 months ago.
B. Anyone trying to play an older ROM of thwaite will have to futz with their input settings every time the ROM is loaded.
That is not a good trade. Being able to specify standard controllers is nice metadata, but solves almost no problems for the user, it's what the emulator would be doing by default in every case anyway. Really the important use cases for this field were things that needed non-standard controls.
On the other side, it creates a setup problem for the user who wants to play thwaite... and it's really hard for an emulator author to get around this with UI, it's inherently asked for by specifying the controllers, the only option left is to abandon (i.e. turn off) the feature, which defeats the purpose of having it in the first place.
So... that's what I'm getting at. My goal isn't to make you do more work on some ROMs, it's to have a spec that doesn't create new problems for the users. The byte 15 proposal is very good to have, and I really did like it going in. The only problem I have is the meaning of $00, the rest of it is fine. You can still have the metadata to specify standard controllers too! ...but it shouldn't be $00.
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.
Bregalad, we've already had that argument, and we've already discarded it as self-contradictory.
Please re-read starting here:
viewtopic.php?p=227528#p227528
NewRisingSun wrote:
Which games were released in NES 2.0 format that do require something other than standard controllers?
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+.
rainwarrior wrote:
but let's start with allpads and thwaite.
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.
NewRisingSun wrote:
one of which is not a game
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?
tepples wrote:
these programs gracefully degrade when the expected expansion controller isn't present.
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.
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.
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.
(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.
Sour wrote:
Alternatively, I suppose $FF could be used as a "nothing specified" value, if that makes it less annoying to change.
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.
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.
rainwarrior wrote:
that's a different effort that would need to be coordinated with NewRisingSun (if they haven't given up entirely on this)
What part of "
disavow" do you not understand?
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).
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.
Bregalad wrote:
Headers should describe the cartridge. (..) So this information (which "input" a game supports) has nothing to do in a NES header.
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.
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.
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.
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.
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.
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.
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 see. You are not too indifferent to sabotage the entire effort, but you are too indifferent to help fix the mess you have created.
@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?
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.
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. Edit: NewRisingSun corrects me on this but it's not my main point....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.
NewRisingSun wrote:
Therefore, the microphone can be emulated at all times, and list item $01 can be removed, to be replaced with standard controllers.
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.
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?
NewRisingSun wrote:
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 see. You are not too indifferent to sabotage the entire effort, but you are too indifferent to help fix the mess you have created.
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?
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.
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.
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.
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:
Why were you happy with microphone in the spec a few days ago when you pushed the wiki edit and not now?
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:
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?
zeroone wrote:
What's the general approach to padding and will it work for all the games?
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.
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
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".
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?
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.
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.
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.
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_DeviceA 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?
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.
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?
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.
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.
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?
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?
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.
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!
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.
Yeah sure, if nobody else comments on it by monday night I'd say that's perfectly reasonable.
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)
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.
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?
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.
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.
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?
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.
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.
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.)
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.
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.
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.
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 [ 248.49 KiB | Viewed 7833 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.)
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.
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".
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?
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.
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.
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.
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.
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?
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.
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.
Is there any reason to think that programs may have instead done "LDA #4 / BIT $4016" ?
Seems unusual, but I can check.
No licensed Japanese ROM has A9 04 2C 16 40.
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.
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)
Kaiketsu Yanchamaru is in the list as "undetermined". Super Chinese 2 does query the microphone, but the code is too convoluted for hvcmic to identify.
Two recently-released famiclone built-in ROMs (Thumbs-Up 240-in-1 Mini Arcade Machine, Polaroid Megamax GPD001SDG, available at the "usual place") use an encryption scheme that simply swaps bits 5 and 6, but only of CPU opcode bytes, and are otherwise identical to the normal VTxx console types. I tentatively denoted mapper 256 submapper 15 in the released ROM images to indicate this, given it was likely used for the same purpose as the
other submappers of mapper 256. But I am not sure that is the right spot to do it, given that it has nothing to do per se with what a mapper normally does. But I am also hesitant to use any other header bits to denote something that is really idiosyncratic to a particular type of famiclone. Any ideas or opinions?
On one hand, it is a unique CPU, and arguably should be in the Extended Console Type.
On the other hand, every VRTech console except the VT01 makes no distinction between memory mapper, CPU, and PPU anyway, so in these situations the two fields are really redundant anyway, and shoving this craziness into a submapper makes it easier for emulator authors to quarantine the crazy.
Okay! I have now added this encryption type to mapper 256's submapper table.
I've noticed that the wiki page for NES 2.0 got an overhaul... I'm not sure if the new format is an improvement over what we had before, but regardless of opinion, I'd like to report that some of the ASCII diagrams are busted (the first 2 for sure), as the lines aren't correctly connecting some bits to their descriptions.
The diagrams are literally just ASCII and spaces with no tabs in a monospaced font. I don't see how this could go wrong, but a picture of what you see would help us figure out if there's anything we can do to fix it.
Here's what looks wrong to me:
Attachment:
wiki-ascii-diagrams.png [ 28.51 KiB | Viewed 12306 times ]
Oh, huh. Those are actually typos. Fixed.
tokumaru wrote:
I'm not sure if the new format is an improvement over what we had before
It's always nice to see the appreciation one gets here for one's work. Maybe I should re-add some of the better parts of the old page, such as the rant about battery-backing the "stupid CHR RAM" and which cartridges are "monstrosities"?

Anyway, thank-you for pointing out the typos.
Sorry if I sounded ungrateful or something, it's just that I felt slightly disoriented when I went to look something up and found a completely different page. And without comparing them side by side I couldn't really tell what has improved and what hasn't. I do appreciate the effort to make the wiki better, so sorry if I sounded mean.
Didn't see in the Wiki that the Famicom Network System (Modem) controller is added to "Default Expansion Device". Guess we could add it preemptively as "$2F" as Ben Boldt figures all this stuff out?

rainwarrior wrote:
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.
Another might be the Famicom emulator in the Nintendo Switch (free download from Japanese eShop and region-free). I can confirm that the headset port does not work (or at least I couldn't get it to work) with Zelda though, so I guess you need those Famicom-style controllers that supposedly has a microphone. The 3DS VC is another possibility, I have no Famicom VC games on my 3DS though.
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.
Thanks for your hard work! There are many new games to the list I didn't know about. I don't see one of the most famous examples, Hikaru Shinwa: Paluthena no Kagami, in there and I have never found the code searching the disk image manually either. I'm starting to doubt that the game actually supports the mic as I have never gotten it to work nor have I seen proof of it working. I'd love to be proven wrong though.
Pokun wrote:
I don't see one of the most famous examples, Hikaru Shinwa: Paluthena no Kagami, in there
In the context of NES 2.0 headers, I only looked at cartridge games, and Parthena no Kagami is a Disk-System-only game. (The U.S. version, Kid Icarus, which was released on cartridge, does not use the microphone.)
Pokun wrote:
I'm starting to doubt that the game actually supports the mic as I have never gotten it to work nor have I seen proof of it working.
At any general store (i.e. one where you are greeted with イラッシャイマセ ナンデモヤデス, not where you are greeted with ドヤ イッペン コウテミヤヘンケ), blow into the microphone while holding the A button on the second controller to raise or lower the prices.
Oh I see, so the entire FDS library is still unchecked.
OK I just tried haggling in Mesen and now it does indeed work right away. I used the TOSEC dumped disk and Mesen, I guess I must have used a bad dump before (the No-intro dump is known to be bad), and for real hardware I guess it's just my mic that is bad (although it is good enough for other games like Zelda).
I know you had already figured it out, but I did post visual proof of the microphone working to haggle the shopkeeper down on original hardware several years ago :
https://www.youtube.com/watch?v=aF_TynJ-c6w