News: 11 March 2016 - Forum Rules

Author Topic: Working Infinite Lives code for Batman Forever SNES to use with Game Genie Guy  (Read 779 times)

MysteryMan3D

  • Jr. Member
  • **
  • Posts: 36
    • View Profile
The one code that's been spread across the Internet (C964-CF04) doesn't work. Can anyone here help me find an Infinite Lives code for the game that DOES work? It has to be Game Genie, since GG Guy doesn't support Action Replay codes.

Hacker65xx

  • Jr. Member
  • **
  • Posts: 21
    • View Profile
HI

AR code is:

7E0017:09

FAST6191

  • Hero Member
  • *****
  • Posts: 3237
    • View Profile
Could be a fairly interesting porting exercise for yourself if you want.

For those just joining us then classically there are two types of cheat cartridges.
Game genies. These sit between the cart and and game and when the console requests a section of code the game genie cares about that boot it will return a modified version but otherwise pass it through. Naturally this means it is trivial to patch a ROM with a game genie code.
Basically everything else (action replay, pelican, codebreaker, goldfinger, gameshark...), these inject small pieces of code that once a frame or something will write a given piece of RAM. For most 16 bit and older and GBC and older stuff it is quite hard to patch codes in -- less power than is ideal, often tricky to find space, many different ways of running ROMs. GBA and newer often have tools that will do this for you, and I saw some N64 stuff a while back.

As time went on and new consoles released this varied a bit (names bought and sold, brought back, some gaining minimal ROM editing abilities, game genie gaining a few RAM codes for some iterations), and some save editors are crept in. Newer stuff still that does not reference the cartridge directly in code (CD based consoles, the NDS and newer) instead copy the binaries to RAM to run from there and thus you can edit binaries (which is the logic the games run with) which means you can backport a lot of those to simple patches quite easily (compression tending to be the main thing getting in way of fun there).

Editing RAM is generally considered easy, because it mostly is. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial being my general choice for a basic guide to RAM based cheat making, it is for the GBA but works much the same for basically everything (some newer devices take pointers, or indeed ASLR, to the extreme but still fundamentally that). https://doc.kodewerx.org/ details codes, https://doc.kodewerx.org/hacking_snes.html for the SNES (if the link is down do a search for "enhacklopedia". http://problemkaputt.de/fullsnes.htm#snescartcheatdevicescodeformats is also good stuff.

Editing a ROM is generally considered harder, and usually is. This also serves to explain where game genie codes are often more far reaching and quite rare compared to RAM stuff.


Turning RAM stuff into a ROM patch, or indeed a game genie code, has two main avenues of approach.

1) You edit the instructions that edit the RAM.

2) You replicate what the cheat engine does and once a frame you send out a write to the RAM to edit your value.


1) If you know the RAM location (see basic cheat making above) then you can set a breakpoint in your debugger to tell you about what edits that (presumably break on write). Change subtracts to adds, or indeed "NOP" (short for no operation, basically you want an operation that has no effect on the rest of the program -- many assemblers will give you one even if the console does not have it, writing a general purpose register value to the same general purpose register tending to be the default most hackers opt for if not) and you have your cheat.
The trouble comes... I usually use Mario as an example. Time runs out, lose a life, jump in a pit, lose a life, poison mushroom, lose a life, hit an enemy, lose a life, hit a hazard, lose a life, get crushed, lose a life... and while I believe most Mario games have a death routine (all those might call the death function which is the sole thing to handle losing lives) that you can change there then there are many games and aspects of games that might have some 30 different bits of code edit the same RAM value which gets tedious (though possible if you are editing a ROM rather than using usually limited amounts of game genie code slots).
You can get a bit more creative as well and do things like make no damage be taken by enemies (might stop knockback as well that normal game might do, especially if it is proportional to damage). You can also do a more creative workaround -- infinite continues instead might be an option and there are typically far fewer things that will edit the continues value, or if the score wipes typically associated with those are no good then you can edit the game to have something add to the lives counter such that you never realistically will run out of lives (make the standard pickups add a life as well as score/ammo/whatever, or any extra lives instead add 100).


2) Here you would have to find something that executes a lot, or add your own. Most for this would use "vblanks" which is a section in basically every bit of code where once a frame the console will execute a section of code (usually supposed to be for updating the screen, vblank being short for vertical blank, but if you can sneak a write data to RAM in there then that is fine too).
Main problem tends to be finding the vblank (easy enough if you can play assembly editor already, if you are new to it then maybe not) and the related one of what in programming is called a race condition but generally falls under timing related concerns. If your edit happens at one point but the game has already say taken the value of health and done its calculations then if the damage taken is greater than your health value you die before the RAM edit had a chance to take place*. Not such a problem for a simple lives counter you are presumably keeping above just one life (or 0 lives if it is a game that rolls that way before giving you a game over).


*there is also the related problem of data on the stack instead of RAM, though this is probably less of a thing for the SNES than it is in later consoles. The idea however is similar and the data is read from the RAM and kept in the CPU with it doing operations on that before being written back to the RAM. This however is then a perfect candidate for the instruction stuff mentioned in 1)

MysteryMan3D

  • Jr. Member
  • **
  • Posts: 36
    • View Profile
Could be a fairly interesting porting exercise for yourself if you want.

For those just joining us then classically there are two types of cheat cartridges.
Game genies. These sit between the cart and and game and when the console requests a section of code the game genie cares about that boot it will return a modified version but otherwise pass it through. Naturally this means it is trivial to patch a ROM with a game genie code.
Basically everything else (action replay, pelican, codebreaker, goldfinger, gameshark...), these inject small pieces of code that once a frame or something will write a given piece of RAM. For most 16 bit and older and GBC and older stuff it is quite hard to patch codes in -- less power than is ideal, often tricky to find space, many different ways of running ROMs. GBA and newer often have tools that will do this for you, and I saw some N64 stuff a while back.

As time went on and new consoles released this varied a bit (names bought and sold, brought back, some gaining minimal ROM editing abilities, game genie gaining a few RAM codes for some iterations), and some save editors are crept in. Newer stuff still that does not reference the cartridge directly in code (CD based consoles, the NDS and newer) instead copy the binaries to RAM to run from there and thus you can edit binaries (which is the logic the games run with) which means you can backport a lot of those to simple patches quite easily (compression tending to be the main thing getting in way of fun there).

Editing RAM is generally considered easy, because it mostly is. https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial being my general choice for a basic guide to RAM based cheat making, it is for the GBA but works much the same for basically everything (some newer devices take pointers, or indeed ASLR, to the extreme but still fundamentally that). https://doc.kodewerx.org/ details codes, https://doc.kodewerx.org/hacking_snes.html for the SNES (if the link is down do a search for "enhacklopedia". http://problemkaputt.de/fullsnes.htm#snescartcheatdevicescodeformats is also good stuff.

Editing a ROM is generally considered harder, and usually is. This also serves to explain where game genie codes are often more far reaching and quite rare compared to RAM stuff.


Turning RAM stuff into a ROM patch, or indeed a game genie code, has two main avenues of approach.

1) You edit the instructions that edit the RAM.

2) You replicate what the cheat engine does and once a frame you send out a write to the RAM to edit your value.


1) If you know the RAM location (see basic cheat making above) then you can set a breakpoint in your debugger to tell you about what edits that (presumably break on write). Change subtracts to adds, or indeed "NOP" (short for no operation, basically you want an operation that has no effect on the rest of the program -- many assemblers will give you one even if the console does not have it, writing a general purpose register value to the same general purpose register tending to be the default most hackers opt for if not) and you have your cheat.
The trouble comes... I usually use Mario as an example. Time runs out, lose a life, jump in a pit, lose a life, poison mushroom, lose a life, hit an enemy, lose a life, hit a hazard, lose a life, get crushed, lose a life... and while I believe most Mario games have a death routine (all those might call the death function which is the sole thing to handle losing lives) that you can change there then there are many games and aspects of games that might have some 30 different bits of code edit the same RAM value which gets tedious (though possible if you are editing a ROM rather than using usually limited amounts of game genie code slots).
You can get a bit more creative as well and do things like make no damage be taken by enemies (might stop knockback as well that normal game might do, especially if it is proportional to damage). You can also do a more creative workaround -- infinite continues instead might be an option and there are typically far fewer things that will edit the continues value, or if the score wipes typically associated with those are no good then you can edit the game to have something add to the lives counter such that you never realistically will run out of lives (make the standard pickups add a life as well as score/ammo/whatever, or any extra lives instead add 100).


2) Here you would have to find something that executes a lot, or add your own. Most for this would use "vblanks" which is a section in basically every bit of code where once a frame the console will execute a section of code (usually supposed to be for updating the screen, vblank being short for vertical blank, but if you can sneak a write data to RAM in there then that is fine too).
Main problem tends to be finding the vblank (easy enough if you can play assembly editor already, if you are new to it then maybe not) and the related one of what in programming is called a race condition but generally falls under timing related concerns. If your edit happens at one point but the game has already say taken the value of health and done its calculations then if the damage taken is greater than your health value you die before the RAM edit had a chance to take place*. Not such a problem for a simple lives counter you are presumably keeping above just one life (or 0 lives if it is a game that rolls that way before giving you a game over).


*there is also the related problem of data on the stack instead of RAM, though this is probably less of a thing for the SNES than it is in later consoles. The idea however is similar and the data is read from the RAM and kept in the CPU with it doing operations on that before being written back to the RAM. This however is then a perfect candidate for the instruction stuff mentioned in 1)
Could you do me a favor and just convert the code for me? I'm a gamer but I'm not a hacker, and that stuff's too advanced for me.

The correct code is 7E001705. I already tried it in Mednafen and it works. It just needs to be converted to Game Genie so I can use it in GG Guy...

Jorpho

  • Hero Member
  • *****
  • Posts: 4948
  • The cat screams with the voice of a man.
    • View Profile
It just needs to be converted to Game Genie so I can use it in GG Guy...
You want a simple answer?

AR codes work in a completely different way from Game Genie codes. It's definitely not impossible, but there is no trivial way to convert these things that can be easily applied to all AR codes.
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!

MysteryMan3D

  • Jr. Member
  • **
  • Posts: 36
    • View Profile
I'm just gonna resort to the Genesis version of the game instead, because that version has Game Genie codes for Infinite Lives that actually WORK. Also, the Genesis version's not as nerve-wracking as the SNES version.
Proof:
https://www.youtube.com/watch?v=mSrQ7_0o44s

Jorpho

  • Hero Member
  • *****
  • Posts: 4948
  • The cat screams with the voice of a man.
    • View Profile
I was going to suggest playing the arcade original on MAME, but that's a completely different game, isn't it?

You might also consider using the DOS version on DOSBox-X.
« Last Edit: July 19, 2021, 02:08:04 pm by Jorpho »
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!

MathUser2929

  • Hero Member
  • *****
  • Posts: 1645
    • View Profile
gamehacking.org has game enhancer cheat creators in the forum.

Kyle

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
This works for me. I didn't play the game much so I hope it works out.

Batman Forever (USA)
C9C2-0F65
« Last Edit: July 19, 2021, 07:30:17 pm by Kyle »

MysteryMan3D

  • Jr. Member
  • **
  • Posts: 36
    • View Profile
This works for me. I didn't play the game much so I hope it works out.

Batman Forever (USA)
C9C2-0F65
It does work. Thank You.

EDIT:
It works, but not completely. You still lose lives in 2-Player Competitive Mode.
« Last Edit: July 20, 2021, 08:38:37 am by MysteryMan3D »

Kyle

  • Jr. Member
  • **
  • Posts: 26
    • View Profile
Awesome! Enjoy Game Genie Guy! I played this game for a bit on real hardware. It is an odd duck. I had to consult Google and Gamefaqs to get through the first couple of levels. I hope you beat it.