NES 2.0 mapper number for various UNIF stuff and Game Genie

I don't know all of the stuff that is currently UNIF-only, but one is UNL-DripGame; we should assign mapper numbers to these things. Another thing that a mapper number should be assigned is Game Genie (FDS already has a number assigned so it doesn't need another one). For grace with emulators that don't support NES 2.0, we can assign these various UNIF-only stuff, as well as Game Genie, into not plane 0. Another reason not to assign UNL-DripGame into plane 0 is because the author of the game doesn't want to.

Game Genie doesn't need a mapper.

Tools don't need mappers.

You can't do anything with the FDS BIOS in isolation, nor can you easily replace it.
You can't do anything with the Game Genie bootstrap ROM in isolation, even though you could easily replace it.
The "slots" model used by MESS to handle Karaoke Studio (m188) and Nantettatte!! Baseball (m68) is irrelevant because the extensions that are added aren't usable on their own.
Mapper 100 is effectively a jersey barrier with blinking lights, saying "Bridge out".
Mapper 248's nominal assignment for development is nonsense. If you're developing a new mapper there's no reason to use mapper 248 as opposed to anything else.

I think the Game Genie menu and FDS boot animation are both worth emulating, but I'd be really surprised if NROM wasn't sufficient to handle both of those.

Game Genie + Cart doesn't really have much value as a mapper, IMO. It's a modulation of every mapper, not a mapper by itself. A lot of emulators are already doing the right thing with it, I think.

As for drip game, I'm surprised it hasn't been assigned yet.

Game Genie and FDS are both NES/Famicom cartridges (although Game Genie takes a parameter being another cartridge; FDS takes a parameter that is changeable at runtime being a disk image for one side of one disk; other mappers also take parameters (the syntax of these parameters is implementation-specific)).

Have the principles:

• One NES/Famicom cartridge = one .NES file
• Same NES 2.0 header = same function of cartridge (not including ROM data)
• These principles are from the functional view, so different hardware implementations with the same function have the same header, and also that CIC and lockout defeat are not part of the Famicom VM.

Other notes are that tepples has mentioned "lock-on" of certain cartridges (my idea of parameters is a generalization of this it seems), and koitsu, even though he disagrees about its usefulness, has said that regardless of what he thinks there should be a mapper number for Game Genie in order to have consistency since FDS BIOS already has one!

The "series of simple gates masquerading as a CHR ROM" act exactly like CHR ROM and have its same function, therefore if a NES 2.0 header is given it should be treated like a CHR ROM and the data given explicitly in the file. (Note what I wrote about the "functional" principle above; I know this wastes 8K (actually 20K) of disk space but that isn't a lot in this case and anyways improves the simplicity of the system.)

I agree that mapper 248 assignment is nonsense (although it may have been assigned before NES 2.0 was invented?).

Apparently there is other currently-UNIF-only stuff too other than UNL-DripGame, but I don't know of any. If you do know of any, please post it on here.

Also, an emulator using these tool mapper numbers doesn't even prevent the old way from working too; here is an example of a kind of "modular system":

• If the main file the emulator is told to load does not have a NES 2.0 header then look in the configuration file to determine what to do; if it doesn't tell what to do, then if it is a old iNES header then internally convert to NES 2.0 otherwise display an error message.
• If a mapper takes a parameter being another cartridge, that cartridge's mapper might also take a parameter.
• You can have support for -G for Game Genie codes (perhaps it would be useful to support hex codes instead of (or in addition to) the ones Game Genie uses?); this is different because if gamegenie.nes is used then the game start with PPU already is ready; if the emulator's internal patching function is used then the PPU isn't ready when the game starts.
• One possibility for the configuration file's code to do if it finds it is a .FDS image: Find the save directory for that game inside of the user's save games directory; if not found, create it and unpack the .FDS into files disk1a.qdi and so on into that directory. After that, start disksys.nes with that save game directory as the current directory and disk1a.qdi as its parameter. (The mapper option screen will then display the disk sides to easily switch between them.) (Note: Depending on the implementation, it might support the configuration file creating the NES 2.0 image in RAM from fdsbios.rom)
• After the cartridge is loaded you can check for the user parameters; if some parameter is not specified, you might use a default, use none if the parameter is optional, ask the user for that parameter, or display an error message; it depends on the implementation.

Doesn't the FDS firmware rely on FDS hardware? (e.g. the custom sound hardware or the fact video memory is writeable) But then again it's basically "boot FDS firmware like it was a Famicom with FDS attached".

Yes, and the FDS hardware is a Famicom cartridge.

I meant that it could be duplicated as an NROM with probably very minimal changes.

Actually, yeah all you really need is an emulator that has a no-disk state for its FDS emulation. (You can do this in FCEUX by ejecting immediately after loading an FDS file.) Emulator support for FDS BIOS is already pretty robust, I think? It also has an assigned mapper already, but I don't know if there's any reason to create rips with it.

I just checked, and there is a working NROM game genie .NES floating around. I don't know what problem would be solved by designating a mapper for it, though. An emulator author could implement a Game Genie mode that uses a ROM like this as the menu, and lets the user specify the cartridge to stack with it. I think this is an emulator UI problem, not a mapper allocation problem. What do you want a Game Genie mapper number for, zzo38?

There are some other cartridge stack situations like the Aladdin Deck Enhancer, but even though the physical form is special, the ROMs aren't, really. Each of the compact cartridge plugins just boils down to a single NES file rip, pretty simple. (iNES mapper 071, I think?)


As for things that actually do need a mapper allocation, aside from drip game, tepples mentioned some Chinese UNIF-only rips by CaH4e3, but I don't know who that is or where to find the rips. Maybe these mappers are defined in the source of some popular emulators?

So, I suppose what you're getting at is that you like the symmetry of treating FDS as an NES file. Probably want you want to do is create a mapper 20 NES file for the FDS bios, and then create an emulator that boots this and has a UI for loading disks.

At any rate, the mapper is already allocated. I would guess the only reason this isn't done is because we already have good working emulation solutions and nobody really cares about the file format symmetry. You have to load the associated disks anyway, so I presume most emulator authors figure you might as well just open them directly like any other file, rather than having the additional step of loading the BIOS NES first.

Actually, you know what, after thinking about it that way I want to change my position on this, slightly. I think a (plane 1?) mapper for Game Genie and the Aladdin Deck Enhancer would both be fine.

Though I would suggest the same requirement for this as I would for any other mapper allocation. Implement it first, publish the results, and then allocate the mapper. I think it's perfectly reasonable to ask for an allocation to support a living, real solution. Mapper allocations for proposed/theoretical ideas, on the other hand, waste everyone's time.

1. Create and publish the ROMs that require it. (Not just theorizing they could exist.)
2. Create and publish an emulator implementation that uses them. (Working, not just a design draft.)

The impediments to this I've already outlined (i.e. we've already solved the problem for FDS, Game Genie, and Deck Enhancer, and the proposed idea might seem like pointless busywork in pursuit of ideology rather than practical implementation),

OK, although I am not sure about plane 1 for Game Genie. If the planes are analogous to Unicode (for example plane 2 for Chinese), then you might assign Game Genie into plane 14 (which in Unicode is the "Supplementary Special-purpose Plane"). This is only for organizational purposes though (was it originally tepples's idea?) and if other people decide that plane 1 is better, use plane 1.

Unicode has nothing at all to do with the NES format. There is absolutely no reason to organize anything about it based on unicode.

Honestly it'll probably take us at least another 15 years to fill up plane 1. The reason I wouldn't suggest putting them in plane 0 because they lack new utility (the problems are already solved other ways), so they don't have enough value for allocate plane 0, IMO. You could actually just allocate them as submappers of 020, alternatively, and just stick every "tool" mapper there?

That much I absolutely agree with; I suggested the same thing originally too. (I thought tepples wanted it like Unicode, but of course you don't have to.)

However there are two other things considered, which are Datach (mapper 157) and Aladdin Deck Enhancer.

With mapper 157, the implication that the EEPROM is shared across all games that ever use this mapper violates the first principle. Fixing it involves the following two ideas:

• If the PRG ROM amount is nonzero, then the .NES file represents a cartridge with its own EEPROM and the game built-in, separate from any other .NES files. (Since there is only one game that uses this, this fix won't break any existing .NES files, and even makes it easier to manage save games. There might exist a few emulators that already do this, meaning those emulators don't need to be changed!)
• If the PRG ROM amount is zero (requires updating the NES 2.0 specification so that it doesn't default to 16K like old iNES), then the mapper takes a user parameter being the ROM image for the game itself, and uses the EEPROM allocated to the .NES file originally loaded.

I found no information about Aladdin Deck Enhancer in NESdev wiki, but if I understood properly what was discussed on IRC, Aladdin Deck Enhancer violates the third principle. Assigning a mapper number won't actually give that mapper number any meaning (if I misunderstood how Aladdin Deck Enhancer works then I am likely wrong and you can please correct me).

This reminds me, the way Fusion handles firmware is that they aren't loaded directly (as they could refuse to boot), but rather there's a "no game" state where the firmware boots as-is. It has that for both the Sega CD and the Master System firmware. I can see this logic working perfectly for the FDS firmware as well.

It is, by definition, impossible to create a ROM that requires the Game Genie hardware be present.

The registers are either available for writing and have no effect; or the boot ROM is NOT MAPPED, the registers are not available for writing, and three locations in memory are substituted.

So you can only use the Game Genie hardware to make something that's basically an NROM subset... in which case it should be stored AS NROM.

Similarly, the process of creating a firmware replacement for the FDS BIOS is so difficult that it practically speaking won't happen: it requires that you disable reads/writes to the FDS hardware to $E000-$FFFF AND you cannot just solve this by only disabling /ROMSEL or M2.

Thirdly, I strongly object to reserving mappers for things that don't exist in hardware.

That is one of the worst arguments I've ever heard. It's just the sunk cost fallacy.



The Aladdin Deck Enhancer is nothing but CHR-RAM, a lockout defeater, and a simple UNROM-like bankswitch mapper. The PRG-ROM itself is on a daughtercard. The hardware, when combined, is already assigned to mapper 71 or 232 depending on how the daughtercard wires things.

Wrong; Game Genie does. If emulated as NROM you may be able to get the display, but it won't do anything then after that. Game Genie has extra registers and what I called a "user parameter" (or what tepples called a "lock-on"). In this case the user parameter is another .NES cartridge file.

The fact that the existing hardware implementation makes it difficult is irrelevant (it is equally nonsense to avoid assigning a mapper number if the ROM chip of a game cartridge is inside of anoter IC; notice my third principle). It is still a Famicom cartridge, and the BIOS is the ROM data of the cartridge.

I am agree too but Game Genie is actually exist in hardware.

I don't agree with his argument either; I have my own argument, I'm just mentioning it in case someone doesn't like my argument.

Exactly that; that's what I have been saying!! Aladdin Deck Enhancer does not need a mapper number (the exception would be if it had battery-backed CHR-RAM, but I am pretty sure that it doesn't).

I'm not entirely certain what that definition is, but in the case of Game Genie, I meant a Game Genie boot ROM as an .NES file. Part of the mapper implementation for the emulator would be to select another .NES file to stack with it. Yes it's a very simple (almost trivial) mapper, aside from the extra file selection involved in the emulator implementation, but I don't think its simplicity is a point against it.

The advantage, though, is that you could emulate Game Genie + ROM in a slightly more "native" way, letting you play through and/or debug the transition from Game Genie boot to game.

Does anyone need this? Probably not, but if someone built (past tense) a working implementation of ROM + emulator that needs it, I see nothing wrong with allocating an NES 2.0 mapper (or 020 submapper) for it.

Another argument against it is that there's nothing stopping the emulator author from just implementing a special Game Genie mode that emulates its boot state and mapper. The .NES ROM format doesn't need to be involved. Unlike most single-instance mappers, a Game Genie mapper probably requires too much special case UI for stuffing it into the .NES format to be of any convenience.

Regardless of whether it's emulated as NROM, the Game Genie will never do anything after that. All it will ever do is damage your toploader's slot and crash for lack of CIC in a frontloader. A ROM on a game genie cartridge cannot tell that it isn't on an NROM cart with the Game Genie's weird CHR-ROM-like thing.

We already have a well-established model of how to support the FDS and Game Genie (for people that so love that awful chunky UI): the BIOS/bootstrap are stored as a separate file NOT IN .NES encapsulation. Allocating a mapper for them just obfuscates things.

And its sole purpose is playing FDS games, and you can't use it to do anything but play FDS games, and you can't replace the BIOS with anything else, and emulators often skip the low-level emulation of the FDS in order to not make the user wait real-time while it loads things. Storing these images in a .NES encapsulation is explicitly vouching for the awful UI of making the user select File 1 then File 2 using a file chooser.

But alternate bootstraps for it don't. And even if you go right now and hack something up, it still doesn't make sense to store that alternate bootstrap as a .NES file; it works perfectly well as an isolated raw dump.

MESS doesn't store their BIOSes with their game images either.


And that's a far better way of phrasing my argument.

UI is implementation-specific and isn't about mapper numbers. (Also nothing stops you from making an alias or shell script in your command shell (to avoid the inconvenience offered); that also has nothing to do with mapper numbers.) (And even more so, nothing stops the emulator from supporting multiple formats!)

The iNES format is two ROMs, combined with a mapper number that dictates a recipe of functionality needed to run those ROMs as intended.

In the case of Game Genie, whether you want to call it UI or not, selecting a second cart to stack with it is part of that functionality. If you make it a mapper, it needs a way to select the second cart.


Mappers are not really a catalogue of hardware implementations. We've got better places to try to organize that information. One of the best things about the iNES mapper system is that we can group compatible set into a single mapper where sensible, and it keeps the implementation work down. The iNES mapper is an abstraction layer that categorizes the cartridge hardware into practical, functional groups. This is a big part of why UNIF was not popular; it made it harder to implement all the necessary functionality.

There's a big difference between FDS and Game Genie. Unlike the FDS BIOS, which contains functions that games call, the Game Genie ROM is not required for basic functionality of Game Genie codes. A lot of emulators use complete high-level emulation for Game Genie code support, as does the PowerPak. So an emulator might support FDS, Datach, and that baseball game through lock-on but not Game Genie. A pure NES emulator not intended to have any Famicom functionality might even support no lock-on at all.

Apart from nostalgia, debugging the handoff from Game Genie to your game might be one reason to use a Game Genie ROM. For example, you might want to detect whether the system was started with a Game Genie and use that to switch to sissy graphics for the hero. Detecting this might depend on the trash that the Game Genie is known to leave in the sweep registers, as well as whatever the Game Genie leaves in CPU RAM and nametable RAM before jumping to the game. How much does the Game Genie clear before starting the game?

Yes, as I said, some emulators might support the Game Genie ROM in such a file others might use only the high-level emulation, and some might do both or neither; both are useful for different reasons (and if doing high-level emulation, it would also be useful for it to support the codes written in hex). Having the Game Genie ROM at all is mainly for debugging and stuff yes (and, I suppose, nostalgia).

I do not know the answer to your last question but it can be made to be experimented with if you have such an emulator.

The Game Genie doesn't try to clear anything, it would be impossible anyways for the Game Genie to completely hide. No matter what the GG does, you could search RAM for JMP ($FFFC) to detect it.

I actually have been customizing the GG ROM and using it to debug the Cheapocabra bootloader. Originally, I went through and optimized the official ROM (and fixed a few bugs). Reassembling it with blargg's bootloader just barely fits. But to speed development along before I write a server program, I've made a totally new ROM with a simple bootloader using the good old XMODEM protocol.

Would be cool if there was emulator that allowed an NES program to read/write a virtual COM port (look up "com0com" if someone wants to bother with it), but that's a topic for another thread, maybe.

If you wanted to detect Game Genie modifications, maybe a better approach would be to CRC the ROM? It would catch the use of codes directly (including their emulated counterparts, and potentially romhacks), and not have to rely on hitherto un-researched hardware details.

On a somewhat related note, I just noticed on the nesdev.com root page, there's a link to an official NROM dump (with permission) of the Game Genie BIOS: http://nesdev.com/genie.zip

Yeah, as long as the CRC is bigger than 16 bits, because it could patch that, too. Or the branch that causes it to detect.

Calling it a "sunk cost fallacy" is begging the question by assuming that assigning FDS BIOS was a wrong decision. If it was a right decision, then allocating a further tools mapper in the same principle is correct. If it was wrong, it seems to have already been decided by the principles of NES 2.0 not to deallocate it.
FDS BIOS is something that goes in the Game Pak slot, as is the Game Genie. Incidentally, "gg.rom" (at least one emulator's preferred location for said ROM) is not obviously for NES; there were other Game Genies.
Well, one can always implement redundant checks, remembering that if you want to catch PowerPak-type GG, as it has 5 codes. (EWJ2 pirate-cart protection, meanwhile...well.)

Daisy-chained GGs (unless the register writes cause all of them to switch to game mode at once; shouldn't, as it would mean passing through things before starting) seems like a situation that is not covered, and a case that is reasonable to have some sort of other interface option to use. It wouldn't necessarily be a reason to force everyone to select two (or more) files.

If someone makes an "& Waluigi" lock-on cart in the style of Sonic & Knuckles, that also seems not-covered, though I suppose mappers are not for theoretical implementations...
Seeing as I and at least one other prefer choosing files by command-line...no, no it is not.

You could also plug the FDS cartridge into a Game Genie with an adapter, now that I think of it...

These are quite my points! (As well as daisy-chaining Game Genie; since the user-parameter to the Game Genie mapper is an entire other cartridge, its mapper can also take parameters...)

Now that I think of it, the way to defeat Game Genie is to have the code that does the checking mapped to low-cartspace ($4020-$5FFF, $6000-$7FFF), because that's outside of its patchable range, as it uses that bit in codes for "Do a compare?" instead.

But then the Game Genie could still patch the code that calls the code that does the checking. If Nintendo hated the Game Genie that much, it could have designed a more "evil" mapper that doesn't put anything important above $8000-$FFFF. Fixed bank at $4100-$5FFF, switchable bank at $6000-$7FFF, switchable ROM bank at $E000-$FFFF for samples and vectors only. Good luck female dogs.

More specifically, this is what's called a "master code" (the codes you're required to enter if you patch anything are pretty much meant to by-pass modification checks).

A modification check as sophisticated as that of, say, Earthbound is likely to need more "master codes" than the original 3-code Game Genie can provide.