Does DSATM not work for this? It is entirely possible to patch in a code to a game, and possibly far more elegantly than DSATM will manage, but when the end results do the same then why go to the hassle. Cracker (DSATM's author) does have a guide to trainer making that he shared before he made DSATM to make it all easier, you can find it
http://gbatemp.net/threads/crackers-ds-trainer-maker-tutorial.44410/ though in this post I will be covering what is roughly called for as well. If you are doing it with a ROM hack just make the patch after you patch the hack in.
Anyway step 1 is to analyse the code. You do this mainly as codes on the DS do not just have to tickle memory in the conventional sense -- DS binaries are found in memory and overlays can be found there when they are active/loaded as well.
Tools like NDSTS (main binary) and crystaltile2 (overlays) will tell you where things are found in memory.
http://www.no-intro.org/tools.htm
http://filetrip.net/nds-downloads/utilities/download-crystaltile2-2010-09-06-f23649.html
Anyway
023cdce8 00000000
From
http://doc.kodewerx.org/hacking_nds.html#arcodetypes
Type 0x00
32-bit
0XXXXXXX YYYYYYYY Writes word YYYYYYYY to [XXXXXXX+offset].
You specified no offset so we get to ignore that.
0 means 32 bit write (in this case all 0) to 23cdce8, more normally this would read 023cdce8 (you can read 0 codes as addresses but best not to get into that habit).
From
http://problemkaputt.de/gbatek.htm#dsmemorymaps
02000000h Main Memory (4MB)
If it turns out it is a binary or overlay location then find that part of the binary or overlay, you may have to decompress and sort that out if it is there, and change it to read what the code says it should.
I can't be bothered to grab mario kart and see what goes right now so I will assume the second case and it is just normal memory, from now on you will need to have an appreciation of what assembly is and how it works (not fully but what a disassembler is, what an opcode is and general ideas of programming). You have two main options here
1) Full on assembly edit.
2) Remake what a cheat engine/DSATM/action replay/whatever actually does, though maybe on a smaller scale.
Surprisingly enough 2) is often more annoying to pull off, however if you need button activators then it is potentially a better option.
For 2) you would have find somewhere to add your own code that runs every vblank (or however often you need, vblank is normal though) and sets that location to what the code wanted it to be, possibly with a button activator/check (
http://problemkaputt.de/gbatek.htm#dskeypad ). Once again cracker has something for this when he talks about hooking games (
http://crackerscrap.com/docs/dshooking.html ). In a lot of cases this is what tools like gabsharky, GBAATM, DSATM and the like are doing when they patch a game -- it is easy enough to make a generic cheat engine to do all this where hoping an automated tool can find the locations is less easy. Equally something like this is what a lot of cheat and flash cart cheat engines do, however these have a few more luxuries than patching and hackers might have on stock systems. This is also why cheat engines get disabled in clean modes on flash carts.
For 1) you have several options. I usually go for the following two though
i) You break the check
ii) You force something to work that way you want.
You already know 023cdce8 is the location the game watches to tell what CC things are. I am not sure why the game would have used/allowed a full 32 bit value (you have 50, 100, 150 and mirror -- 8 bits is more than enough) but I guess it is what it is and we are not here to discuss the quality of Nintendo's coders/compilers.
On ii) the game will probably read that location into a register (in disassembly it will probably be something like "ldr r3 023cdce8 (or the address will appear next to this in brackets like 023cdce8)").
For 50cc the code seems to be all 00 so you would change that ldr to something like mov r3 00 to make the game ignore the load function and instead just copy the value you want in. Not the most elegant, mainly as the game will do a bunch more afterwards for no great gain, but it works and should not slow anything down at all (beyond now being in 50cc). What is nice with this is if the cheat would crash a game if you went into a bonus mode and it wanted the memory for something else then this patch would hopefully not trouble that.
There are various ways of finding the instruction in question, the most basic is disassemble the binary and do a text search for the location (or ones just either side of it in case it reads a lot more/less than the cheat would indicate). Better is to use a debugger and a break on read for that memory location, fortunately no$gba debugger is now free so you can use that if you like.
For i) after the read will come a bunch of checks, in normal C style code it would probably be a if 00 do 50cc, if 01 do 100c .... else do mirror mode. It kind of works the same way in assembly but the instuctions here are called cmp (short for compare). Here you would find the compare and then the branch instructions (b in opcode parlance), the branches would probably be things like branch if less than instructions or branch if equal to. There are various things that can be done and will vary depending upon the coder and the compiler used.
For a code as simple as the one you are looking at here there is little point in messing with the checks and branches, in many other cases though you might want to mess with them, or the things they do/lead to. For instance in normal Mario if you fell down a hole you would not be able to jump out, however you could find the instruction that removes from one from the lives counter as a result of said death and change it to leave it the same/add one/take more lives, equally for more unpredictable things like anti piracy if you can change the check/jump so it never goes down the "AP check failed" path and always takes the "AP check passed" one then you would do that rather than fiddling with return values. That said the better AP patch might be to never do the check in the first place -- these checks have demonstrably slowed down several DS games so improving a game as well as removing AP is great, however we are getting off topic.
I cover both methods in slightly more depth (and with pictures) in my hacking docs, the memory read thing is covered in my advance wars Japanese language patch section, the checks I believe should be in the infinite health cheat for summon night 2 on the GBA (the GBA is similar enough to the DS in this regard for it not to matter).
