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)