How I've been pronouncing nicknames of two regulars in the NES emulation scene:
Anyway, it appears CaH4e3 and others dumping Asian games have been assigning iNES mapper numbers that conflict. This problem in fact dates back to fwNES, where there was at one time a separate space of "fwNES mapper numbers". So in #nesdev, zeromus recently proposed a way to clean up mapper support. We traced this to the lack of a central registry for mapper numbers.
Someone said he prefers board names over mapper numbers. But there is no one-to-one or even one-to-many relationship between mappers and boards. SxROM encompasses several functionally related boards, and boards like UNROM can be configured for two different mappers based on which 7400 series chip is in one position. Some boards don't even have recognizable names. (See UNIF#Shortcomings for the details.)
Until now, the best practice on the wiki has been to update the Mapper page based on Disch's docs at RomHacking.net and based on the source code of FCEUX, Nintendulator, and Nestopia. This resulted in, for example, the allocation of mapper 28 to a multicart mapper whose design I led. But some dumpers, such as CaH4e3, have gone off on their own and assigned mapper numbers proprietary to their own emulators.
The proposed solution involves a bit of pre-allocation of the NES 2.0 mapper space. I propose to lay it out in "planes", roughly like Unicode when it expanded past UCS-2:
It also involves a series of numbered memos posted on the wiki and signed by several major emulator developers. These memos describe enough of the known behavior of one or more mappers to emulate one or more specific games, and this may involve defining new mapper numbers or revising the expected behavior of existing mappers.
A memo would have at least these:
It was first proposed that these would be sequential, but because some memos might take longer to develop, that might not be the best way. How do OpenGL extensions and IETF RFCs get their numbers?
- zeromus aka zeromuis: Zero Mouse (Danish, Latin, Norwegian, Old English, Faroese, Icelandic, Afrikaans, Dutch) (also the final boss from Final Fantasy IV)
- CaH4e3: Sanchez (Russian)
Anyway, it appears CaH4e3 and others dumping Asian games have been assigning iNES mapper numbers that conflict. This problem in fact dates back to fwNES, where there was at one time a separate space of "fwNES mapper numbers". So in #nesdev, zeromus recently proposed a way to clean up mapper support. We traced this to the lack of a central registry for mapper numbers.
Someone said he prefers board names over mapper numbers. But there is no one-to-one or even one-to-many relationship between mappers and boards. SxROM encompasses several functionally related boards, and boards like UNROM can be configured for two different mappers based on which 7400 series chip is in one position. Some boards don't even have recognizable names. (See UNIF#Shortcomings for the details.)
zeromus wrote:
I define a mapper number as "a series of specifications which cause you to be able to emulate a ROM" that may correspond to 1 board or a dozen boards.
Until now, the best practice on the wiki has been to update the Mapper page based on Disch's docs at RomHacking.net and based on the source code of FCEUX, Nintendulator, and Nestopia. This resulted in, for example, the allocation of mapper 28 to a multicart mapper whose design I led. But some dumpers, such as CaH4e3, have gone off on their own and assigned mapper numbers proprietary to their own emulators.
The proposed solution involves a bit of pre-allocation of the NES 2.0 mapper space. I propose to lay it out in "planes", roughly like Unicode when it expanded past UCS-2:
- Plane 0 (0-255): Basic Multilingual Plane, the current mess
- Plane 1 (256-511): Supplementary Multilingual Plane (mostly for new homebrew mappers)
- Plane 2 (512-767): Supplementary Ideographic Plane (Chinese dumps)
- Plane 15: Private use area (not for publicly distributed dumps)
It also involves a series of numbered memos posted on the wiki and signed by several major emulator developers. These memos describe enough of the known behavior of one or more mappers to emulate one or more specific games, and this may involve defining new mapper numbers or revising the expected behavior of existing mappers.
A memo would have at least these:
- Titles of games affected by the memo
- New mapper numbers (if any)
- Summary of changes to existing mappers' behavior (if any)
- Links to specific revisions of wiki pages about the affected mappers
It was first proposed that these would be sequential, but because some memos might take longer to develop, that might not be the best way. How do OpenGL extensions and IETF RFCs get their numbers?