NES 2.0 mapper number for various UNIF stuff and Game Genie

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by rainwarrior »

lidnariq wrote:
rainwarrior wrote:1. Create and publish the ROMs that require it. (Not just theorizing they could exist.)
It is, by definition, impossible to create a ROM that requires the Game Genie hardware be present.
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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by lidnariq »

zzo38 wrote:
lidnariq wrote:It is, by definition, impossible to create a ROM that requires the Game Genie hardware be present.
Wrong; [the] Game Genie does. If emulated as NROM you may be able to get the display, but it won't do anything then after that.
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.
It is still a Famicom cartridge, and the BIOS is the ROM data of the cartridge.
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 the Game Genie actually exists in hardware.
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.

Rainwarrior wrote: 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.
And that's a far better way of phrasing my argument.
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by zzo38 »

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!)
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by rainwarrior »

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

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by tepples »

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?
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by zzo38 »

tepples wrote:... 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...
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.
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by Memblers »

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

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by rainwarrior »

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
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by Memblers »

rainwarrior wrote: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.
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. :D
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

*For* allocating GG

Post by Myask »

lidnariq wrote:That is one of the worst arguments I've ever heard. It's just the sunk cost fallacy.
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.
lidnariq wrote:Allocating a mapper for them just obfuscates things.
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.
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. :D
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...
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.
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...
zzo38
Posts: 1096
Joined: Mon Feb 07, 2011 12:46 pm

Re: *For* allocating GG

Post by zzo38 »

Myask wrote:
lidnariq wrote:Allocating a mapper for them just obfuscates things.
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.
...
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.
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...)
(Free Hero Mesh - FOSS puzzle game engine)
User avatar
Myask
Posts: 965
Joined: Sat Jul 12, 2014 3:04 pm

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by Myask »

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

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by tepples »

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.
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by Sik »

tepples wrote:But then the Game Genie could still patch the code that calls the code that does the checking.
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).
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: NES 2.0 mapper number for various UNIF stuff and Game Ge

Post by tepples »

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.
Post Reply