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.
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 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?
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/
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?
- 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.
- 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.
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 :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.
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"
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 NES2tokumaru wrote:it's supposed to contain information describing the hardware inside the cartridge.
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.
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.tepples wrote:NTSC/PAL bit matches the lockout chip.
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.And I thought Vs. System games put the PPU on the game board, not the system board.
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.
- 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 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 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.
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.