As above you are hardpatching a cheat.
You start by finding the RAM location (some might use saves but we will skip that for now) for the item you want or a related one*. Finding cheats is a field unto itself with much you can learn** but for the sake of having something https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
It is for the GBA but frankly it is not really any different whether you are on a vic20 or a modern PC, other than the modern PC maybe having things appear in different locations in memory where older stuff tends to be fixed.
*if I am doing an inventory cheat I will tend to make it for items I can easily buy, use and sell before turning around and using that info to locate the super rare only dropped one every 2000 battles end game sword or something.
** for instance there is a reason the vast majority of games you see a "moon jump" cheat for will have a double jump/jump in air feature. If you find where the game stores the "double jump has already happened" flag and set it always be "has not yet happened" you get infinite double jumps and away you go. Most of the rest will be where you can have some jump/speed stat set ridiculously high or a gravity feature in the game itself rather than hardcoded every frame you move this much/speed up by this much).
Anyway from there you have RAM location(s) for what you want. As most systems don't allow you to edit RAM, or doing so is just annoying you met why converting it to something you can hardpatch as a ROM might be a better plan.
For newer systems then there are tools that will attempt to automatically patch things. These sorts of things are often harder, considered impossible short of AI or a lot of effort, to have as an automated tool for older systems though -- newer stuff in many ways is often a lot simpler to older stuff, has a lot more spare resources and might even have some things that make it even easier to work with. General cutoff here is anything older than the GBA or anything 16 bit and older will probably not see automated tools for this one and thus anybody that wants to do this will have to get their hands dirty, and even on the likes of the PS1 and N64 you will struggle to find tools as nice as some of those which later systems get.
As above you have two methods
1) You recreate what the average action replay/codebreaker/gameshark/... does and inject a small piece of code that runs every frame (every frame on most systems will be a dedicated point in a game's operation to do things, typically this will go under the name vblank as in vertical blank which covers when things can happen for a screen but also useful for simple cheats). This is also why some infinite health or whatever cheats might still see you be able to be one shot killed by a super powerful weapon -- if it takes all your health at once, or your health does not recover in time as it has to wait until next frame.
Find the vblank routine and do a simple memory write (will vary between systems as to what goes here -- some will have a dedicated method or two, others will be able to do it directly from normal instructions) to the RAM location. You can also do some more complicated logic in this like only when below a certain amount then set it high, or do things to work around crashes if you have cheats enabled but if you have them on with the opening credits or a certain point it crashes.
2) You edit the game itself.
Somewhere in the game will be a programming construction that runs something like
During vblank (or some other period, might be an interrupt)
IF health = 0 then jump to death routine
ELSE return to game.
There will be another for mana if casting a spell, bullets for a gun, potions if using those, money in a shop...
If you know the location from the RAM you you get a debugging emulator (don't know what we are suggesting for the megadrive/genesis right now -- they tended not to be as well developed as the NES, SNES, GBA, DS and PC but still had something) and use breakpoints (possibly watchpoints) to monitor that area. Typically you will want break on read (bpr in most emulators) for things that you care about reading -- things like do you have enough money to buy this. For things that you care about decreasing (say lives when you die, HP when you get hit, mana when you do a spell, bullets...) you will probably be looking more at break on write.
There are other types of breakpoints (break one execute for example) but that is what the help files of such things are for.
Anyway set a breakpoint on the RAM address you found with a cheat search. Anything that reads or writes (depends what you set) that location will see the emulator say "hold up something just read/wrote this area" and list all that came before it. Part of this might be an addition or a subtraction and you can change that to be something you want, or just nothing at all (see "NOP" -- short for no operation, you basically overwrite an instruction with another that does nothing at all other than waste a cycle).
Other times will be something like above where it is IF ELSE, though in most assembly languages it will be a compare (CMP) and then a jump or a goto depending upon the results of the check. Here you can make it ignore the compare and always take the good path. While not strictly what you will be doing here then imagine if you had a save you edited, the save however contains some complicated maths function it does to make sure it is not changed from what the game originally wrote. You could find this complicated function out and replicate it, or you could edit the game so when it does this function and compares the result to what it expects then you basically make it always take the "it's fine" path even when it is not. Bonus there is the game next time it saves will probably fix the checksum/hash for you and thus make your edited save appear perfectly valid.
This also sees you never have to die, maybe even never have to have a hit register (and thus no knockback, no stopping firing, no reset of combo...) if you go back far enough.
Infinite time is often a tricky thing to do in games as games might also use the time to decide behaviours in game (plenty of games might trigger something with only so many minutes to go, or simply only move enemies when the timer is changing), or letting it go over a limit might put you in a situation the game never expected (if the game only ever expects there to be 10 minutes on the clock then letting it go over might start overwriting more important things) but this is also where editing a ROM might prove to be easier by being able to dodge these. Other times people will do things like press this key combo to reset time, do this in game action to reset time or similar.
Never the less the basic approach is much like anything else in that you find the time location via the same thing you would use to find a health number/bar (do nothing else in the game but let time go on, search for a change, let time go on, search for a change...) and from there you figure out what goes and how you might twist it to your purposes.