@FAST6191 thank for reply,but i need an example of where to put the HEX codes and then see them converted to ARM.
So you have a bunch of conventional cheats (usually left as hex.
https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial is for the GBA but the principle works on most systems, though pointer codes are common the later you get in systems so pay extra attention to those. enhacklopedia
https://doc.kodewerx.org/ covers cheat formats on older systems, not sure what to link for the vita but whatever emulator or cheat program you use should have a breakdown of the formats for a given newer system) and want them running on the ROM/emulator without the need to do anything? This is usually called hardpatching cheats.
https://gbatemp.net/threads/crackers-ds-trainer-maker-tutorial.44410/ is very old and for the DS but the general process is the same whether you are on a commodore 64 or latest 64 bit processor to even think about playing PC game.
Two main options.
Get a debugger (don't know what emulators have here, what external tools there might be for emulators for this system or whether you have to use hardware like the original PSP and some playing on the DS in earlier days). Set break on write (possibly break on read as that might happen earlier) to the area addressed by the basic hex code (or make a cheat that does it). Do something that changes it (fire a bullet, lose a life, use a spell, spend some money... whatever the code deals with really).
The debugger should trigger saying this instruction from this location* did the deed. Now it will probably be a basic write but prior to that (which a basic debugger will include) will have been a bunch of calculations to generate the number to write. Subtract 1 from lives value now becomes add or NOP so very easily and thus jumping in the pit adds a life or does nothing depending upon what you did (again hopefully losing lives is a single routine and not 50 different things corresponding to all the ways you might die, in which case you have 50 different things to handle).
Find the vblank routine (should be obvious and happens say 60 times a second and is a type of interrupt so should be reflected in the CPU flags and such so eh). Find some space in the code (jump to a new location, optimise some code, overwrite some unused data, add it to the end of the list...) and add in a write to the location dictated by the cheat. This is what most classical action replay, gameshark, codebreaker, gold finger, pelican... cheat devices were doing. Might not work in some scenarios if the write happens too late (calculate damage, massive damage so health is zero, oh OK death, at that point your write comes in too late. I used to use such things in N64 Goldeneye as an example as it was a good one -- put in an AR code and then go eat a rocket/explosion, you will die where bullets do nothing and in game invincibility cheats work fine). Does however dodge the 50 different things tickling the same area and all needing their own modification problem.
In either case it is not so hard to add a compare to check for conditions to happen (be it controller state or some more complicated "I want health in this range but never more than this" type deal), or in said working backwards through code figure out a concept you don't like (maybe you disable poison damage in a RPG but leave everything else in the damage calculation, or you half the damage it does by adding in a shift to the calculation at a relevant point). Congratulations you are now an assembly hacker doing real stuff. It gets more and more interesting with more and more subtle but also game changing options you can go in for from here -- fancy moon jump as you understand gravity in the game, understanding structures to in turn edit levels, subtle rebalancing of game mechanics (there is a reason I linked the pokemon stuff earlier, most games have something like this at their heart doing things but that is an example of notable complexity that most reading this would understand at some level), disable checks on money so you can buy the most expensive items in the game (where the write command earlier might do for a hardcoded cheat then it will likely have been preceded by a read to make sure you had enough money to buy it in the first place, same also applies to health codes but now you also don't get any knockback as the enemies never hit you in the first place/do 1 damage, one way of doing equip anything as well but you could also figure out the flags on which classes/characters can equip and edit the game's internal weapon data accordingly as a big boy ROM hacker).
Some will go for more brute force methods, do a static (or grab dynamic from debugger) disassembly, search for anything tickling the location you found for your cheat. Can work and being a text search takes a few seconds to try at best.
*If you are dumping RAM then this location will be part of the binary, as likely will be things surrounding it. If your debugger somehow does not have a disassembler of its own (it should, they are fairly basic to make, and if it is a debugger you will also have the added perks of knowing what mode the CPU is in and what flags are set. Your online link you started this out with being the equivalent of the text box I wrote this site gave me to reply in compared to the formatting options of a professional document layout program). Though the location of binary in RAM is probably obtainable from ROM info tools used by hackers, emulators and more besides as it has to know what file to copy and where to copy it to in memory to in turn run the game, not to mention stuff in RAM is usually uncompressed and unencrypted if that is going to be a thing (though there are downsides in some cases like not all code being there if it is not needed -- why waste space holding the credits animation sequence if that plays once every 100 boots/50 hours? This is called dynamically linked code, DLL in Windows world, overlays in DS games, various WRAM loaded code in GBA games and variations on the theme in most consoles ever. Some games will also remove code from memory in a bid to up security -- try not to include encryption keys after they are no longer needed but games is less likely to see this. Hopefully nobody is going to throw self modifying code into a game at this point in time -- most programmers got together and decided self modifying code is bad news in the 80s and nobody has really done it since). I don't know what is available for the Vita in this regard but it really is a basic concept that many of those above will need and thus make. That said the vita is not that well supported as these things go, is relatively new and relatively complex compared to some things so you might be advised to drop down to a better supported and somewhat simpler device, on the other hand it is doable enough it seems (several examples out in the wild) and if it is the thing that will hold your interest then the project you will do is the thing to learn on.
https://www.romhacking.net/documents/361/ covers how to find graphics in a GBA game with a debugger (albeit a rather old and command line based one), a process generally called tracing. General principles work much the same for anything though. I don't have a good guide to ARM assembly for beginners and don't think there is likely to be one. To that end learn the basics on the PC
https://www.plantation-productions.com/Webster/ https://stuff.pypt.lt/ggt80x86a/asm1.htm and then move sideways, ARM themselves and a thousand other places will have the listings of instructions and various breakdowns of how they work in that case (not necessarily the same as the PC but will be close enough for most purposes and if it clicked for you then it is nothing drastic).