[HotCoffee]

I'm trying to find the address that contains the player health in "Kirby Super Star"(SNES) but I don't know how to.
I'm using Mesen-S for emulation and it also has a memory view but I don't know how to look for that value.
I also searched online for a memory map of some kind but found nothing relevant to the player health.

[FAST6191]

I struggle to imagine there not being existing cheats for this sort of thing.
https://www.almarsguides.com/retro/walkthroughs/snes/games/KirbySuperStar/GameGenie/ is game genie (so a ROM edit which can be trivially patched into a ROM, says your health gets low but nothing will happen, so presumably stops death instead of caring about health)
https://www.almarsguides.com/retro/walkthroughs/snes/games/KirbySuperStar/ProActionReplay/ has a few more RAM based affairs which are harder to patch in on the SNES and probably always will be this side of strong AI.
If you need a start on decoding such things https://web.archive.org/web/20191123185800/https://doc.kodewerx.org/hacking_snes.html

One usually uses a cheat search tool for this sort of thing. Emulators tend to have their own, especially for stuff as popular as the SNES, but you can also find external ones (emuhaste, cheat engine, artmoney and many others)

In an ideal case you would have a lot of health and a minimally damaging thing you can sit there and take damage, search for anything that changed, take damage, search for anything that changed...
For platformers like kirby where you tend to have maybe three health this gets more annoying as two or three chances tends not to narrow things down, especially when "has changed" rather than lowered or specific values are searched for, might not be enough. You can boost it a bit with savestates (restore one from when you had full health and search again for has changed as it will be full again hopefully, then start once more on losing health and searching, repeating as necessary), and "has not changed" searches (if you don't take damage then the health will presumably not have changed), and if you have some kind of health restore nearby (or from a cheat/level edit) then that too can be used.

If you are better at hacking there will usually be a graphical representation of health/damage taken. Anything that causes the graphical change (be it health boxes or some kind of reaction animation) will ultimately have fed from the same thing that fiddles with health and thus you can work with that. This gets into tracing and assembly hacking though which can be a bit much, especially when a tedious half hour with a cheat search will probably still do the job. However assembly type things is also where you might stop knockback from happening*, or annoying sounds related to health being low (or enemy behaviours that might change depending upon your health).

If those links at the start are not for your region then they can still be valuable -- while the location within the RAM might change the general arrangement tends not to -- if the score is 10 bytes ahead of the health or whatever in Japanese it will probably still be that in the US and the PAL and whatever sub arrangements there are. If score is then easy to find (it is score after all, big numbers going up from easy actions) then you can go sideways from there to investigate, it is certainly how 99% of "all weapons" cheats get made or rarely modified stats.

*sometimes games will use enemy damage to determine distances here, you could find the calculated damage or something that goes into the damage calculation (say give your character 999 defence in RPGs) with normal cheats.

[MysticLord]

https://gamehacking.org/?game=43469&hacker=all&format=genie

Infinite Energy for Kirby by Ugetab
Game Genie
40137C:46

[HotCoffee]

I decoded the game genie codes and managed to find the health address but now I have another problem.
I don't know if I should make another post for this or continue this one:
I can't find what writes to that address, I tried setting a breakpoint on the debugger and set it to both "read" and "write"
but it only stops when something reads that address.
There must be something that writes to it because the health changes when the player takes damage.
But it can't find it.

[FAST6191]

If it is a game genie code then it is probably going to be a ROM alteration (some game genie stuff has limited RAM bothering). Game genie codes then tend to alter the game's internal logic; rather than doing something that constantly writes a given memory location it will instead do something that either prevents death entirely (if health = 0 then goto death routine gets skipped over sort of thing) or stops health from being subtracted from that location by making the thing console twiddle its proverbial thumbs. This would also by why it is only reads that trigger it -- you tend not to write to ROM with the whole read only thing going on.

[phonymike]

A lot of these codes seem strange to me. Lots of the GG codes aren't encoded, and the PAR codes (which modify RAM locations) seem to modify the SA-1 SRAM not the snes's internal WRAM (SA-1 $40137C mirrors $00737C.) Usually PAR codes begin with 7E or 7F indicating the snes's WRAM.

But this one does seem to work from bizob66 at gamespot: Game Genie, 3. Infinite Health 62E2-AD61

I used ucon64 (command line alert) to decode it

Code: [Select]

ucon64 --snes --ggd=62E2-AD61
and it gives

Code: [Select]

62E2-AD61    = 01FBD2:8D (CPU address: 01FBD2)
All the snes GG codes I've ever seen modify the game's assembly code in ROM, and not RAM values. So whatever was at $01FBD2 is probably game code and will be changed to 8D. So you can set an execute (not read or write) breakpoint for 01FBD2 (I use bsnes plus).

It turns out at $01FBD2 you'll find (with DB = $00)

Code: [Select]

lda $737c
The 8D from the GG code changes lda $00737c into sta $00737c thus not checking your health.


So what is $00737C? Well that's not a typical snes memory address (Lunar Address says it's reserved). Since Kirby's got the SA-1 expansion chip, this address seems to be mapped to SRAM. Gotta check Fullsnes.

Memory Map (SNES Side)
00h-3Fh/80h-BFh:6000h-7FFFh  One mappable 8Kbyte BW-RAM block
40h-4Fh:0000h-FFFFh          Entire 256Kbyte BW-RAM (mirrors in 44h-4Fh)

So the snes stores Kirby's health at the beginning of SRAM + 137C. Since SRAM can be moved around in hardware using the SA-1, you can access it from the locations below:

the game reads from 00:737C
00-3F:737C (mapped ram begins at 6000 + 137C)
40-4F:137C

It looks like the SA-1 (not the snes CPU) writes the value when you get hurt...

Looks like we opened up a can of worms, good luck with that!

[FAST6191]

Well that took an unexpected turn.

I now wonder if it is anti cheat, anti pirate, dodging RAM mapping or something else that causes this.

[phonymike]

At this point I assumed all SA-1 games were lorom because of their header location, but it looks like they can change their mapping (lorom/hirom) at any time.

As for kirby, I'd guess that the game engine is run mostly on the SA-1, where it calculates how much health you have. And then the snes cpu might be used to just update the display. You'd have to dig into the code to find out.

[KingMike]

All the snes GG codes I've ever seen modify the game's assembly code in ROM, and not RAM values. So whatever was at $01FBD2 is probably game code and will be changed to 8D. So you can set an execute (not read or write) breakpoint for 01FBD2 (I use bsnes plus).

Probably because a REAL GG works by intercepting data as it passes through the cart connector.
They also lack the pins needed to make any expansion chip games work. (it has the pin slots for such carts to fit, just no actual pins to enable functionality)

Of course, implementations built into flashcarts will probably not obey those limitations.

[pianohombre]

If you edit Kirby's health in the memory the CEO of Nintendo Japan cries a tear, and you don't get the true ending.