It's one of those things that I didn't even know about until Viper pointed out that code some years back. And the only references I can find through Google all come EnHacklopedia (which I wrote myself, so that's no help ...) I need to better document my sources. By that, I mean the disassembly/reverse engineering that I did on the code type stuff. If I had those pieces of information on EnHacklopedia, it would be even easier to re-research.
Anyway, this is extremely easy to use. But there's a catch (of course!) I believe that only one DEADC0DE can be used at a time. So if you have several large ranges of data to write, you should only convert the largest one. There are other limitations as well, but I can't remember all of the details (more reasoning for documenting sources...)
Taking your example code, here it in converted to a shorter format which should work great:
Code:
81A94FA9 < -- start move set code
81A95004
81A95100
7E2EF810 < -- player 1 modifier
849818A9
84981904
84981A00 < -- end move set code
85C463EA < -- start of making room for my jsr (guess I could have used a branch to my jsr here to save using 1 additional code)
85C464EA
85C465EA
85C46622 < -- start of jump to below routine
85C46780
85C468FF
85C4697F
DEADC0DE
7FFF8004
C91000D0 < -- my routine for fixing fan lift/air fan throw.
03A90400
0A0AAABF
E2C4856B < -- rts
This *should* be correct.
I seem to remember this code type doing something strange when the address is in ROM (like the Starfox code). I believe in that case, it would issue a ROM patch at that address which inserts a JMP
long instruction (4 bytes). The actual data sits in external (GameGenie-onboard) memory, and requires a JMP
long at the end to go back to the original location + 4. But this is all coming from memory, and I could be wrong...