First, you need to know about the types of CPUs used by the GBA, DS, and 3DS. The GBA used an ARM7 CPU. The DS primarily uses a more powerful ARM9 CPU, but the GBA's ARM7 processor is also included on the motherboard. This was primarily to ensure that the DS could be backwards-compatible with GBA games, but some DS games also used the ARM7 as a secondary processor. Pretty much the same thing happened during the upgrade from the DS to the 3DS: the 3DS uses a new ARM11 CPU, but it also includes an ARM9 processor for backwards compatibility with DS games.
Like I said, some DS games use the ARM7 in addition to the ARM9, so in order to be backwards compatible with DS games, the 3DS needed to be able to handle ARM7 instructions. Unfortunately for Nintendo, the ARM11 just wasn't powerful enough to emulate the ARM7, so they ended up having to include an actual ARM7 processor on the 3DS motherboard too. So to recap, the 3DS has
three CPUs: the ARM11 (its main CPU), the ARM9 (the main CPU used in "DS Mode"), and the ARM7 (the secondary CPU in "DS Mode").
It's also worth noting that there are limitations on how these three processors on the 3DS can communicate with each other. The ARM7 doesn't even recognize either of the newer processors. The ARM9 recognizes the ARM7, but because the ARM7 doesn't recognize it
back, communications between the processors is one-way-only. That is, the ARM9 can "listen" to what the ARM7 "tells" it, but it can't "say" anything back. The relationship between the ARM11 and the ARM9 is similar: the ARM11 can read information from the ARM9 (and by extension, the ARM7), but it can't write anything to it in return.
The TWPatcher program is the key to making these DS analog control hacks possible. Specifically, it includes a function called "RTCom", which, through some kind of programming wizardry, allows the ARM7 processor to read data from the ARM11. Honestly, even I'm not completely sure how it works, but what matters is that it
does work.
So, the first thing that you have to do to get this hack to work is to use TWPatcher to patch the 3DS's firmware (specifically, the part of the firmware that handles running DS games in backwards compatibility mode) with the "RTCom" function. And here's where the Action Replay code finally comes into play. The AR code alters the game's internal programming to do a few different things:
- First, it sets up the ARM7 processor to read the 3DS circle pad's input data from the ARM11 via RTCom.
- Then, it configures the ARM9 to read that data from the ARM7.
- At this point, the ARM9 performs a series of mathematical functions on this input data to convert it into the same format as the input data provided by the DS's touch screen.
- After that, the AR code sets aside an unused portion of the game's memory and has the ARM9 store the newly-formatted circle pad input data there.
- And finally, the parts of the game's code that handle analog control input are redirected to read their input data from these memory addresses instead of from the touchscreen like they do by default.
Now that I've explained how this whole process works, it should be pretty clear why this won't work in melonDS. melonDS is a DS and DSi emulator. It's not designed to emulate any of the 3DS's unique hardware, so it doesn't even know what the ARM11 processor
is. And as a result, the AR code won't do anything on the emulator (or on the original DS/DSi,
or on the 3DS if RTCom hasn't been properly activated). After all, the ARM7 can't be expected to provide the input data for the AR code to process if the processor that sends it that data either can't communicate with it or
doesn't exist.
... Hey, I
did warn you that this would be a long explanation. But if you actually
did bother to read through all of it, I hope it cleared up any confusion you might have had regarding how this hack works.
