Yeah I read the same thing.
So they're actually .. Downclocking the "Nintendo DS Chip" to play GBA Games.
Actually, there is no DS hardware soldered on the 3DS board.
Seems like DS mode acts like virtual box, in the sense that anything that runs inside the computer you simulate, won't affect the 3DS itself (Part of a reason we run antivirus tests in virtual box).
If that's the case, all that DSTWO has to do is reprogram the virtual machine that Nintendo set up so it allows you to perform anything else with the remaining memory and CPU.
My guess is, they will search for a way to redirect NAND calls to the SD, sort of like Gateway.
This. It's virtualization and not emulation.
Basically there are 4 ways nintendo could have handled things the way they did... Emulation, virtualization, native, or hardware locking.
Native would be a DS game running as if it were a 3ds game. Nintendo wouldn't do this because of the fact that the original DS protection is terribly broken and it would be have a negative impact on compatibility (running games too fast, broken timings, etc)
Emulation would require software (everything, or at least almost everything done via CPU) translation of all CPU/GPU/Timings/etc. This would be needlessly complex and a very big battery drain and may not even be feasible given how little we know about the 3DS' true hardware. It also leads to unnecessary compatibility issues (since the hardware is so similar anyways)
Hardware locking would be much like how the Wii plays gamecube games... It basically restarts the system in a 'compatibility' mode where the Wii hardware is locked out and the GPU/CPU are underclocked to match the cube. Theoretically perfect simulation, but then lacks all wii features.
Virtualization is thus the best choice and is kind of a combination between the two above methods. Both the hardware and software have to be designed with it in mind... The software basically sets up a "computer in a computer". The innie (in this case the DS) lacks any ability to interact with the outtie (in this case, the 3DS) while the hardware is designed to be able to split work between the two tasks. This allows you to have an actual 3ds menu while playing DS titles... While without the system being hacked to be sure, we can assume that the reason why most of the regular 3ds features are probably disabled to insure proper timings inside the VM DS, or that certain features of the CPU which are necessary for certain other functions (like wifi controller on DS) are locked to the VM so there is no resource conflict leading to an ugly screen of death.
