It is currently Sun Jan 21, 2018 5:41 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Sun Apr 26, 2015 2:23 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5985
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 2:28 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6643
Location: Seattle
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.

Quote:
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 2:31 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 952
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!)

_________________
.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 2:58 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5985
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 3:18 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 4:03 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 952
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.

_________________
.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 4:30 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3501
Location: Indianapolis
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.


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 4:46 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5985
Location: Canada
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


Top
 Profile  
 
PostPosted: Sun Apr 26, 2015 4:54 pm 
Offline
Site Admin
User avatar

Joined: Mon Sep 20, 2004 6:04 am
Posts: 3501
Location: Indianapolis
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


Top
 Profile  
 
 Post subject: *For* allocating GG
PostPosted: Sat May 02, 2015 12:28 am 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 953
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.
Quote:
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...
Quote:
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...


Top
 Profile  
 
 Post subject: Re: *For* allocating GG
PostPosted: Sat May 02, 2015 11:03 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 952
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.
...
Quote:
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...)

_________________
.


Top
 Profile  
 
PostPosted: Wed May 06, 2015 4:14 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 953
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.


Top
 Profile  
 
PostPosted: Wed May 06, 2015 5:12 pm 
Offline

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


Top
 Profile  
 
PostPosted: Thu May 07, 2015 12:13 am 
Offline

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


Top
 Profile  
 
PostPosted: Thu May 07, 2015 5:12 am 
Offline

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


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 30 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: MLX and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group