Homebrew DS(i) Mode hacking progress thread

  • Thread starter Thread starter Billy Acuña
  • Start date Start date
  • Views Views 810,781
  • Replies Replies 4,367
  • Likes Likes 81
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.
 
  • Like
Reactions: Billy Acuña
Just to bypass signature checks.

nope. From the github page:
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 )
 
Last edited by piratesephiroth,
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 it may works since libnds implemented some dsi compatibility for touchscreen and sound even before the sd card access was properly implemented. If there is testers interested with sudokuhax on dsi I can try to provide a build of nds-bootstrap targeting the dsi.
 
Last edited by ahezard,
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.

Is the header of the srl the way the console knows what hardware rights the title has?
I believe the DSi is designed so 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?
 
Last edited by metroid maniac,
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?
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).

By the way if you really use and love the solutions developed in this thread that unlock the 3ds dsi mode possibility (NitroHax, NTR launcher, nds-hbmenu/nds-bootstrap), please donates to nocash (http://problemkaputt.de/). All of this is possible thanks to the nocash gbatek documentation and no$gba debugger. nocash spent months of full time work to have the dsi emulation available in no$gba.
 
People are trying to get gbaemu4ds to work and I'm just sitting playing using Virtual Console to play GBA games.
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.
 
So, uh, I'm actually pretty outdated regarding progress, but I have a few questions, dunno of they've been asked before.

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)

I'm in no rush to get SD loading, just wanted to clear some doubts :3 good luck, and great job so far o/
 
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?

Because of the nature of the patching, there are going to be a lot of kinks to work out. Compatibility bugs and the like.

Would actual game performance take any hit?

Yes, particularly when it comes to streaming data.

Would it be possible to have cheats?

Should be.

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)

I'm actually hoping for this out of my flashcard...
 
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...

Streaming data?

And I see... That's kinda a bummer, but it was to be expected D: I was hoping it would help supersede DS flashcards as a whole, tbh. SD loading would be more of a community effort (testing, reporting bugs...) Compared to depending on flashcard teams.

Thanks for the info c:
 

Site & Scene News

Popular threads in this forum