I have not got a decent 3ds setup anywhere around here to do a blow by blow, and I am not sure it would help much other than to follow the exact same steps. I have a worked example for the GBA in
https://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/ if you really wanted.
Anyway are you familiar with basic RAM cheat making?
You will get an emulator cheat search (or a program that works with memory dumps).
It will give you a bunch of options to compare to the contents of memory at the last dump. Greater that, less than, same as, different to, equal to this, within this range... to use as you will.
Your first job would be to find where the lives value is kept. You can try direct numbers if you like (do remember games use hex and the search might not) but I tend to find it easier to do greater than/less than and difference searches. If you had say a life bar, time bar... instead with no direct numbers you would be doing the greater than/less than stuff anyway.
So you are in the game. Start the search thing. Now you would lose a life (jump in a pit, hit an enemy...) and do a search for something either less than or different to the starting point. Lose another life, do another search. Lose another life, do another search. During all this then things that did not change in the right way will be dropped from the list. If fewer and fewer results are being dropped each time but the list is still too big it can be helpful to mix it up and just let the game run for a bit, do as little as you possibly can (don't die though) and then do a search for things that remained the same.
Eventually you will find where the game stores its lives counter.
Here you can make the classic action replay/gameshark/codebreaker/whatever code with this address you found for the lives counter.
For something like this most are happy enough with that but there are people that can run ROMs but can't use cheats so you can go a step further and edit the ROM.
Not all emulators will have debugging tools but there are usually ones made you can use.
This debugger will have a feature called breakpoints. They break (as in stop -- see the button on your keyboard probably near print screen and scroll lock) the game at a given point that you tell it to. Here you would take the location you found in the simple cheating finding thing above and tell the breakpoint that if anything writes to that location to stop the game and tell me what is happening then.
So you have set the breakpoint and now play the game. Presumably you would die or gain a life and the debugger would stop everything and say something just reached out and touched that area you said to watch. This is what it was doing and this is what happened just before it did.
This what did the deed and what happened before is what you would study to figure out what it is doing. If you went to the location in a disassembler (another tool that is part of debugging, your emulator might even have one inbuilt but IDA is one if not) you would also be able to see what happens next. In an emulator you could also do something called next instruction so you can advance one instruction at a time and see what happens after that.
This figuring out what it is doing will require you to understand at least some of the so called assembly instructions. In practice most assembly instructions are simplistic things that do a very small task, but line up enough of them and you have computing that is useful for people. Even the more complicated instructions are usually just simple maths, but done on a lot of things at once.
Basic ideas of how games work will tell you it probably goes something like this
If [player dies] then do this
Read lives value
subtract one from lives value
check if player now has zero (or negative) lives
if zero (or negative) then goto game over
else write back the value
return to checkpoint/level start
Writing it at a higher level like that is easy but in reality most simple handheld devices (of which ARM devices, and thus Nintendo, does tend to go in for) will mean each step has to be broken down into smaller steps than even that. You need not understand the full nuances of all of those (at least not at first) and you can probably figure out that the subtract one part is all you really need to fiddle with to stop lives from being an issue. Most would tell it to do nothing (the NOP thing covered before) or add a number instead (change the sub to add sort of thing).
You could go further and bypass the whole thing, for other things that might even do better (if you are doing it for health you might also be able to make it ignore any knockback effects at the same time if you go back enough), but if you only have a simple goal then go with that. Go back far enough and you might even be able to find where it detects you touched an enemy and tell it to ignore that -- not only infinite lives but walk through/intro enemies as well.
You might find yourself with a bit of a problem for this -- such a thing is probably not big enough to warrant a real function (programmers use functions to do complicated tasks they have to do a lot in a given program rather than write out the same thing each time). To that end death or losing lives happens in multiple ways and each of those might have their own thing that plays with the lives counter. It is not a problem for the simple cheat thing from before as all that does is hold the one location storing the lives at a fixed value. Some like this as it means you don't have infinite lives but instead can make it so that jumping in a pit gives you a one up but enemies, time, hazards other than pits... all still lose lives.
If you wanted to have infinite lives though then you would either have to find the other things that play with that memory area and sort those. Or you could do what the cheat stuff from the start is doing if it were in hardware and add a small instruction that runs all the time (most use something called a vblank, which is a hardware forced routine that runs every time the screen redraws (so 60 times a second for most things) that constantly writes to the area so it always refreshes. The latter is not without its downsides -- I always remember Goldeneye on the N64. I made a health cheat but the explosions caused so much damage that you would die before it had a chance to refill the health -- normal bullets would not bother you but explosions still could as they did so much. Enough of this detour though.
@
Xdqwerty:
