NES 2.0 Mapper Numbers Request

[zzo38]

I have to request some NES 2.0 mapper numbers for being assigned:

• UNL-DripGame (currently UNIF only; Quietust did not want iNES number, and this may have been before NES 2.0; therefore let's not assign it to plane 0)
• Other currently UNIF only mappers, when known, can be assigned
• Game Genie (as a "tools" mapper, like FDS is; and it is a cartridge with ROM data just like FDS is too)
• If I release any of my own game using custom mappers, to assign numbers to those too (I don't know if reserving a small block might help a bit?)

I don't want to assign any of these to plane 0 or plane 15 (for various reasons, some of which are mentioned above).

[zxbdragon]

I have to request some NES 2.0 mapper numbers for being assigned:

• UNL-DripGame (currently UNIF only; Quietust did not want iNES number, and this may have been before NES 2.0; therefore let's not assign it to plane 0)
• Other currently UNIF only mappers, when known, can be assigned
• Game Genie (as a "tools" mapper, like FDS is; and it is a cartridge with ROM data just like FDS is too)
• If I release any of my own game using custom mappers, to assign numbers to those too (I don't know if reserving a small block might help a bit?)

I don't want to assign any of these to plane 0 or plane 15 (for various reasons, some of which are mentioned above).

UNL-DripGame you have rom?

[lidnariq]

UNL-DripGame is Quietust's port.

There's no sense in having a mapper number allocated for the Game Genie, because it is not useful in isolation.

[zxbdragon]

UNL-DripGame is Quietust's port.

There's no sense in having a mapper number allocated for the Game Genie, because it is not useful in isolation.

thank you!

[tepples]

There's no sense in having a mapper number allocated for the Game Genie, because it is not useful in isolation.

Yet the FDS BIOS theoretically has mapper 20.

[lidnariq]

Yes, but that makes ANY sense because every FDS game uses the same hardware. The Game Genie is an addition to ANY arbitrary hardware.

That said, the allocation of mapper 20 to FDS doesn't make any sense for any purpose other than as an internal bookkeeping number anyway.

[Sik]

The FDS firmware can be run on its own and relies on the FDS as a "mapper", so it makes sense.

For the Game Genie, I guess you could argue that if you use the Game Genie ROM then it'd also make sense for it to have its own mapper number, but in this case you're looking at an emulator capable of dealing with two cartridges simultaneously.

[alphamule]

Which is the proper way... so you'd need an emulator aware of the 2nd slot loading a Game Genie 'BIOS', anyways. Technically boot ROM since it's never called after the game is loaded? But you hear it called that for some reason. It's like if you were to emulate some kind of multiboot device like the demo units that hold several NES cartridges or a hypothetical multicart that had multiple mappers hidden behind glue logic to enable a specific one at once. The emulator will be aware of what that unheadered ROM image file came from, just from the file name or a 'select Game Genie ROM file' dialogue box. GG.PRG could be edited to test out custom features without modifying your Game Genie but AFAIK, the Game Genie ROM is never reloaded until a power cycle/reset, so you can't for example add a Game Shark code, unless you want to modify the cheat device.

Do it like on the No$ (or Playstation) emulators that ask for a BIOS image. A raw image file with no header is actually more useful.

[tepples]

I guess you could argue that if you use the Game Genie ROM then it'd also make sense for it to have its own mapper number, but in this case you're looking at an emulator capable of dealing with two cartridges simultaneously.

Emulators supporting mapper 68 already need to include an "option ROM" image for the Double Cassette connector in that one baseball game. Emulators supporting FDS need to include an option disc image that can be swapped during "SET SIDE" prompts. So the same general "lock-on" principle could apply to all three: FDS takes a disc image, the baseball game takes a Double Cassette, and Game Genie takes an iNES image. But it does start to get complicated if your emulator supports connecting the FDS system card or the baseball game to a Game Genie through an NES-JOINT, and the case of a cartridge with another full cartridge on it might just be different enough.

This wouldn't apply to games using the HES dongle or Super Noah's Ark 3D because those just use the lockout chip, which NES emulators don't bother emulating. The Aladdin Deck Enhancer doesn't have a BIOS, does it?

[lidnariq]

The Aladdin Deck Enhancer doesn't have a BIOS, does it?

No.

[zzo38]

For the Game Genie, I guess you could argue that if you use the Game Genie ROM then it'd also make sense for it to have its own mapper number, but in this case you're looking at an emulator capable of dealing with two cartridges simultaneously.

Yes, if it is applicable to the emulator; not all emulators would work this way, but some can find it useful.

Also, I am considering in this case the Game Genie is in the primary slot; the game then goes in the secondary slot.

If the BIOS ROM are stored with NES 2.0 headers, then the FDS BIOS needs to be twice and the Game Genie ROM four times (unless it is not mirrored?), since the NES 2.0 header specifies in multiple of 16K PRG ROM. (Emulators that use headerless files, or a different kind of header, don't need to do this.)

Of course not all emulators would necessarily do this; these are two different "styles" and some people may prefer one over the other. At least I prefer the one that I am proposing and find the current style less useful!!

Emulators supporting mapper 68 already need to include an "option ROM" image for the Double Cassette connector in that one baseball game. Emulators supporting FDS need to include an option disc image that can be swapped during "SET SIDE" prompts. So the same general "lock-on" principle could apply to all three: FDS takes a disc image, the baseball game takes a Double Cassette, and Game Genie takes an iNES image. But it does start to get complicated if your emulator supports connecting the FDS system card or the baseball game to a Game Genie through an NES-JOINT, and the case of a cartridge with another full cartridge on it might just be different enough.

In all of these cases, they could be implemented as "command-line parameters" to the mapper (if the command-line parameter happens to be another cartridge, that one can take its own command-line parameters). For example:

Code: Select all

famicom-emulator gamegenie.nes gamegenie.nes mario.nes
famicom-emulator disksys.nes -b 1 -pc mahjong_1A.qdi
famicom-emulator nantettatte_baseball.nes extrom1.bin
famicom-emulator dripgame.nes -s -D 30

Connecting the FDS system card or the baseball game to a Game Genie through an NES-JOINT (and other combinations) is a reason to have mapper numbers and command-line interface; this combination of features is useful for emulators that would implement such a thing. (I don't actually know what NES-JOINT is, but I think I understand what is being meant anyways.)

It is not necessary that emulators implement it in this way (not all might want a command-line interface, but I prefer command-line interfaces); it is just a possibililty, and is the way I intend to do it, at least.

In the case of FDS, disk can also be changed at runtime; I do not really like the current way and would like another way, which can be, there is one "eject" command, and another command to select a .QDI file to load, all without resetting the system. (.QDI is a QuickDisk image for a single side of a single disk.)

Also in the case of FDS, starting it with no disk image specified is like turning it on with no disk, so that can be emulated too, since it does in fact do something in such a case.

Another thing of note is that it would also be possible to write an emulator supporting both methods of loading these things. (For example, in the case of FDS: If you select a ".FDS" file to run, it will find a file called "disksys.rom" and use that as the (headerless) BIOS ROM, load disk 1A from the .FDS, and then run it and allow selecting disk sides from that one file. If you select a ".NES" file specifying mapper #20, then it treats the high 8K of that as the BIOS ROM, and allows loading disk sides from individual files. A similar thing is possible with Game Genie, for example to have a checkmark in the open dialog box to allow loading Game Genie at first (or a menu to type in the cheat codes you want); if you instead load the ".NES" file specifying the Game Genie mapper number, that work too but then needs to load another file too, which can be specified as a command-line parameter is one way to do so.)