NES 2.0 Additions Proposal

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Post Reply
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

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.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

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.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

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.
User avatar
rainwarrior
Posts: 8731
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 Additions Proposal

Post by rainwarrior »

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.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

I understand now, it just simply won't work without defining new hardware and therefore should use a new mapper. :roll: Running an NSF and running a game are different things.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

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=19131

3 & 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?
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

  1. 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.
  2. Unknown how one would even begin emulating that. Until that is known, it should not be added.
  3. Same.
  4. 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.
Last edited by NewRisingSun on Mon Oct 15, 2018 10:38 am, edited 1 time in total.
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: NES 2.0 Additions Proposal

Post by Myask »

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.
Image, after all
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: NES 2.0 Additions Proposal

Post by tokumaru »

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.
Great Hierophant
Posts: 780
Joined: Tue Nov 23, 2004 9:35 pm

Re: NES 2.0 Additions Proposal

Post by Great Hierophant »

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 :
Image ;)

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."
Last edited by Great Hierophant on Thu Oct 18, 2018 4:57 pm, edited 1 time in total.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 Additions Proposal

Post by lidnariq »

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.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 Additions Proposal

Post by tepples »

NTSC/PAL bit matches the lockout chip. And I thought Vs. System games put the PPU on the game board, not the system board.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 Additions Proposal

Post by lidnariq »

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.
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.
NewRisingSun
Posts: 1510
Joined: Thu May 19, 2005 11:30 am

Re: NES 2.0 Additions Proposal

Post by NewRisingSun »

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...
  1. several emulators already select expansion devices automatically based on hash tables;
  2. 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...
  1. most emulator users have no access to manuals, especially non-Western ones, or cannot read them because the manuals are not in English;
  2. per-hand selection for every game is cumbersome when trying out a whole set
  3. 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.
VEG
Posts: 53
Joined: Mon Nov 11, 2013 2:55 pm
Location: Minsk, Belarus

Re: NES 2.0 Additions Proposal

Post by VEG »

I propose to merge this topic into the older one: viewtopic.php?f=3&t=2090
I 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: Select all

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.
Last edited by VEG on Sun Nov 04, 2018 2:52 am, edited 1 time in total.
Post Reply