I guess it's not possible to switch to NTR mode within a DSiWare exploit, then?
Otherwise there'd be nothing stopping it working on the DSi now.
I really would kind of like to see a CFW for DSi...
not a CFW but there is sudokohax on DSi
I guess it's not possible to switch to NTR mode within a DSiWare exploit, then?
Otherwise there'd be nothing stopping it working on the DSi now.
I really would kind of like to see a CFW for DSi...
These hacks are specific to the 3DS. They even require TWL_FIRM to be already patched.I guess it's not possible to switch to NTR mode within a DSiWare exploit, then?
Otherwise there'd be nothing stopping it working on the DSi now.
I really would kind of like to see a CFW for DSi...
These hacks are specific to the 3DS. They even require TWL_FIRM to be already patched.

Just to bypass signature checks.Is that simply to bypass signature checks or is there something special at work here?
Just to bypass signature checks.
This unlock new capability in NTR mode without breaking games:
- boost arm9 speed (from 66 mhz to 133 mhz) : bit 1 of register 0x4004004 in ARM9
- SD access : bit 1 of register 0x4004004 in ARM7 + bit ? of register 0x4004008 (value 0x830F0100 works)
- extended WRAM : bit 7 of register 0x4004004 in ARM7/ARM9 + bit 24 of register 0x4004008 in ARM9/ARM7
- slot 1 reset : bit 2/3 of register 0x4004010 ( Follow the sequence desribe here http://problemkaputt.de/gbatek.htm#dsicontrolregistersscfg )
He meant having TWL Firm patchednope. From the github page:
Those patches are required just to use this thing.He meant having TWL Firm patched
So actually there is nothing that prevents nds-bootstrap to run on a dsi, the dldi system contains only dsi code, nothing specific to 3ds. But the compatibility will be lower because there is things you can do on 3ds that cannot be done on a dsi under sudokuhax:
- have the sound/touchscreen controller in ds mode (the only known way to do that is to run a custom srl with modified header so cfw with signature patch is needed). This is the bigger problem.
- switch the bios to ds mode (to do that you need to have unlocked ARM7 by running a custom srl with modified header via cfw)
- access the sd + slot1 (to do that you need to have the access by running a custom srl with modified header via cfw)
For post 2010 ds homebrew they may work since libnds implemented some dsi compatibility for touchscreen and sound even before the sd card access was properly implemented. If there is tester interested with sudokuhax on dsi I can try to provide a build of nds-bootstrap targeting the dsi.
Yes you are perfectly right. The 3DS in DSI mode and a real DSI are working in the same but we have the signature patch in 3ds twl_firm that allows to load custom srl converted as cia. This is theoretically possible on a dsi but it was never achieved. The only thing I know that could lead to that is the special dsi hardmod done by nocash that allows early execution of custom code (details here : http://4dsdev.org/thread.php?pid=1087#1087).Is the header of the srl the way the system knows what hardware rights the title has?
I believe the DSi has a system where the main menu sandboxes titles by disabling hardware they don't need to be able to use before executing them.
In that case, the only TWL_FIRM patch that is needed is a signature patch for allowing illegitimate titles to run, right?
I do that too, but gbaemu4ds will allow us to not have to install the titles on the homescreen. This would allow us to install more games/homebrew before reaching the 300 title limit.People are trying to get gbaemu4ds to work and I'm just sitting playing using Virtual Console to play GBA games.
gbaemu4ds is too much work. Don't count on it ever being finished.I do that too, but gbaemu4ds will allow us to not have to install the titles on the homescreen. This would allow us to install more games/homebrew before reaching the 300 title limit.
Once SD Retail Rom loading is achieved, would it be a superior method to using a flashcard or would there be some sort of kink that would make Flashcards preferable on some cases?
Would actual game performance take any hit?
Would it be possible to have cheats?
Enabling DSi enhancements on DSi-enhanced games? (As in, not forcing ARM9 clock speed to 133 mhz, but just running DSi-enhanced games as though they were running on a DSi)
Still, I would rather use this over gpsp...gbaemu4ds is too much work. Don't count on it ever being finished.
You're better off waiting for dynamic recompilation in mgba. It has no ETA but it's still more feasible than gbaemu4dsStill, I would rather use this over gpsp...
I didn't even hear about that, I kind of gave up on mgba a while ago... Is this official mgba or retroarch?You're better off waiting for dynamic recompilation in mgba. It has no ETA but it's still more feasible than gbaemu4ds
Because of the nature of the patching, there are going to be a lot of kinks to work out. Compatibility bugs and the like.
Yes, particularly when it comes to streaming data.
Should be.
I'm actually hoping for this out of my flashcard...