Usual two links on cheats to start with
https://doc.kodewerx.org/hacking_nds.html https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial
https://problemkaputt.de/gbatek.htm I assume you already have available, it is what the would be GBA and DS hacker has available at all times to reference things.
Hardpatching cheats has two approaches, and third technical one owing to the way the DS works for some things.
1) You find some kind of vblank routine (or other common routine) and add on a little extra code to always write (or some conditional if you want) every time it is activated. Easy enough to find as well for as it is an interrupt you can watch and see the interrupt states. Some people will go for the ARM7 instead (the ARM7 is the weaker of the two processors on the DS, and in commercial games is usually a basic library running executable with not a lot to do and common between games of the same vintage -- you can swap them with no ill effect).
2) You know the area the cheat works for so set a break on usually write* (some will do ctrl+F on a basic disassembly,
https://gbatemp.net/download/ndsdis2-ds-disassembler.28977/ , not saying it does not work quite often but eh) but read might also work depending upon the underlying logic of the game and what you intend.
While the thing doing the writing/reading will probably be just that then the instructions immediately preceding it/following it will be good stuff that speaks to how the game works. Easy enough to change a write a value to be something else, change a subtract to an add, change a IF = 0 then goto death routine...
The third technical one is as the DS binary will be copied to RAM and run from there then some cheats will target that like the game genies of old and edit the binary. You can then copy this edit to the relevant binary (possibly dealing with any compression present) and going from there.
1) Is often quick and easy but risks not working if say the infinite health does not kick in and some enemy does full damage and the game sees this before your hack comes in. I used to use N64 goldeneye as an example here (do a basic infinite health cheat and go eat some rockets) but need to think of a more modern example.
2) Is on its face easy enough but if multiple things write the same area then you get to do it for multiple things (think all the ways you might die in the average platformer, entirely possible each writes to the life counter though many will have a routine everything uses).
*If you are not familiar with breakpoints then they are means of debugging that debugging emulators, debuggers and whatever else tend to feature once they get useful.
Computer memory does three things in classical computing theory/setups.
1) Read from it
2) Write to it
3) Execute code on it
Break points then will mirror this concept and stop emulation, say something just did what you told me to tell you about, here is the state of the system and the last 10 or so instructions that happened before.
They tend to go as abbreviations
BPR = break on read
BPW = break on write
BPE/BOE = break on execute, some emulators will have run to line which is just a special case of this.
Some emulators will have more advanced things (break but only if the number written is within this range sort of thing) that can help.
Logs are also usually a thing here and you don't have to have it halt as much as have it noted when it happens.
no$gba is the main debugger for most of the DS lifetime, desmume has recently gained some nice features on the gdb front (
https://wrongbaud.github.io/posts/ghidra-debugger/ is for the GBA but the principle holds as GDB is a kind of debugging frontend/bridge rather than the whole affair, and allows other things to latch onto it and avoid having to make their own debuggerc) and some tell me melonds has some things. There are some older emulators but... don't.
Tracing is worth knowing about, I usually link people to
https://www.romhacking.net/documents/361/ at this point as it is a nice overview. Basic idea being you find something that is changed by what you want to know about (can be graphical** or sound when you care about the underlying logic, just needs to be something that happens when you do what you ultimately care about) and work backwards until you get to a location in the ROM/binary that deals with it.
https://fceux.com/web/help/Debugger.html is the gold standard in console emulation debugging (only stuff for the PC is better) and everything else is measured against it, DS for my money being right up there compared to a lot of things.
There is a more advanced method featured in some emulators but I don't think no$gba or desmume and its offshoots have it (fceux does, as does vba-sdl-h for the GBA) called trace logging (
https://fceux.com/web/help/TraceLogger.html ) wherein it will note the last new executed piece of code, in which case do everything but what you care about to give it a baseline (so it sees background timers, animations, idle animations, music...) and then the new thing will be your item of interest.
**If I want to know about jumping I could spend ages finding the internal location state via cheat searches, or I could watch the OAM control the location on screen of the sprite and know whatever changes that will also have to speak to the underlying logic about position.
If you are not familiar with assembly then I don't really have any old school ARM based tutorials, so usually point people at
https://stuff.pypt.lt/ggt80x86a/asm1.htm https://www.randallhyde.com/AssemblyLanguage/www.artofasm.com/index.html and say do at least the first few chapters. gbatek has listings for the instructions, as does ARM,
http://imrannazar.com/ARM-Opcode-Map
