Hacking [hypothetical question] RedTWL: Would it be possible with system access granted by current exploits?

[dankzegriefer]

Unlimited DSiWare installs, how so? Sure, you can store DSiWare to the SD card, but you can't run them from it. The idea of RedTWL is to be able to run the DSiWare right off of the SD card. If it could be made expandable, then you'd only be limited by the amount of space that you dedicate for RedTWL.

As for DS game installation, it may not be entirely impossible, but probably not like you'd think. Going for the DSiWare route is probably not going to work, unless research of the Advance Wars: Days of Ruin cia file yields some new breakthrough. Instead, I think that the answer lies in the virtualization processes that control DSiMode, and possibly lies outside of the scope of our current exploits. I have no doubt that it would be a herculean effort like DIOS MIOS or Nintendont, but those apps were able to load games larger than DS roms with less RAM than a 3DS.

The idea is to tap into unused processing potential to create a virtual flashcart for the virtual DSi. The only thing that I could foresee posing a performance problem would be total available processing speed, so such a DS rom loader would have the possibility of being N3DS-exclusive to make use of the extra cores. I also think that any such loader might have a better chance of initial success if focusing on getting unpacked DS games to run before attempting to get .nds file support. It might end up adding steps to the end-user setup, but could save in processing power by not having to decrypt the .nds file on the fly.



What do you define as "making CFW better" at this point in time? We're pretty much at the endgame stages of CFW development. A9lh pretty much signified that we've reached zenith of the primary goal of booting into a CFW. Now is the time where we're going to see more branching development than straightforward, aka the Bells & Whistles Phase. The wireless video streaming that we saw previewed yesterday is an example of that. Not every new development will be viewed as something that objectively makes CFW better, but we're likely to see forks that bring new options to the table for those who want them.

This entire thing makes absolutely no sense and in fact is in no way grounded in reality, the lack of knowledge you possess is actually frightening.

 

[GerbilSoft]

Let's see if I can clarify things a bit.

What would need to be done here is something similar to Wii EmuNAND: instead of redirecting the entire partition, hijack the TWL_FIRM's filesystem code and read individual files from a directory on the SD card. This would allow for "unlimited" storage. It would also allow for a hypothetical Nintendont for TWL to be written that runs DS games from SD.

EDIT: Making use of N3DS's "extra processing speed" isn't applicable here. TWL_FIRM doesn't use the ARM11 for anything (except maybe the Home Menu reset screen?); everything runs on the ARM9 and ARM7. The ARM9 does run at 133 MHz in DSi mode, twice the speed of DS mode, so it is possible that DS games could be run at the faster speed, but again, this would require lots of patching.

 

[dankzegriefer]

Let's see if I can clarify things a bit.

What would need to be done here is something similar to Wii EmuNAND: instead of redirecting the entire partition, hijack the TWL_FIRM's filesystem code and read individual files from a directory on the SD card. This would allow for "unlimited" storage. It would also allow for a hypothetical Nintendont for TWL to be written that runs DS games from SD.

You clarified nothing, because your proposition still makes no god damn sense.

 

[GerbilSoft]

You clarified nothing, because your proposition still makes no god damn sense.

What doesn't make sense here? "Read TWLN files from a directory on the SD card instead of a hard-coded partition." Since it's a directory on the SD card instead of a ~140 MB partition, you can store as many files as can fit on the SD card.

 

[dankzegriefer]

What doesn't make sense here? "Read TWLN files from a directory on the SD card instead of a hard-coded partition." Since it's a directory on the SD card instead of a ~140 MB partition, you can store as many files as can fit on the SD card.

The being able to load DS games part.

 

[GerbilSoft]

The being able to load DS games part.

That obviously wouldn't be doable immediately; you'd need to patch the game executable like Nintendont does in order to redirect accesses from Slot1 to a ROM image on the SD card, since DS games access Slot1 directly.

 

[dankzegriefer]

That obviously wouldn't be doable immediately; you'd need to implement some sort of patching like Nintendont to redirect accesses from Slot1 to a ROM image on the SD card, since DS games access Slot1 directly.

That's not how Nintendont works. Nintendont does indeed patch, but it doesn't use MIOS on the Wii, it patches it to run in WiiMode.

 

[GerbilSoft]

That's not how Nintendont works. Nintendont does indeed patch, but it doesn't use MIOS on the Wii, it patches it to run in WiiMode.

Did I ever say it uses MIOS? No, I didn't. Also, the hardware differences between DS(i) and 3DS modes are significantly larger than GCN to Wii, but that's missing the point: I was referring to the patching process in general, not the specific "it uses WII MODE!" implementation.

This would be patching DS games to work in DSi mode, since the SD slot isn't accessible in DS mode AFAIK.

 

[dankzegriefer]

Did I ever say it uses MIOS? No, I didn't. Also, the hardware differences between DS(i) and 3DS modes are significantly larger than GCN to Wii.

This would be patching DS games to work in DSi mode, since the SD slot isn't accessible in DS mode AFAIK.

You just explained why your point is stupid while defending it. The hardware differences. GCN to Wii in WiiMode worked because the jump wasn't *that* large. DSi/DS on 3DS only works because the 3DS has the original ARM9 processor. Thus the Nintendont analogy is bad. Also magically patching games to work in DSi mode is the mode insane thing I have ever heard.

 

[GerbilSoft]

Also magically patching games to work in DSi mode is the mode insane thing I have ever heard.

And "magically" patching GameCube games to work in Wii mode isn't? (The entire ARAM subsystem had to be emulated, among other things.)

FWIW, according to GBATEK, the major incompatible change from DS to DSi is the touchscreen controller. Everything else is more or less the same.

 

[dankzegriefer]

And "magically" patching GameCube games to work in Wii mode isn't? (The entire ARAM subsystem had to be emulated, among other things.)

FWIW, according to GBATEK, the major incompatible change from DS to DSi is the touchscreen controller. Everything else is more or less the same.

DS-to-DSi. Not DS-to-3DS.

 

[LoganK93]

You just explained why your point is stupid while defending it. The hardware differences. GCN to Wii in WiiMode worked because the jump wasn't *that* large. DSi/DS on 3DS only works because the 3DS has the original ARM9 processor. Thus the Nintendont analogy is bad. Also magically patching games to work in DSi mode is the mode insane thing I have ever heard.

Also the first Gamecube loaders did kind of work that way, as they did patch the mios (diosMios) and then redirected, initially to an sd card, and by the final days of the program USB.

 

[dankzegriefer]

Also the first Gamecube loaders did kind of work that way, as they did patch the mios (diosMios) and then redirected, initially to an sd card, and by the final days of the program USB.

What?
I think you quoted the wrong post.

 

[GerbilSoft]

DS-to-DSi. Not DS-to-3DS.

And I said patching DS games to work in DSi mode, because that would allow use of the SD slot.

Are you intentionally trying to misunderstand what I'm saying just so you can keep pretending that it'll never be possible to run DS and/or DSiWare games from SD?

Also the first Gamecube loaders did kind of work that way, as they did patch the mios (diosMios) and then redirected, initially to an sd card, and by the final days of the program USB.

This worked because Nintendo forgot to disable the SD and USB registers in GameCube mode. In DS mode, the SD slot is disabled; hence why DSi mode would be needed.

EDIT: Actually, there's a register SCFG_EXT that controls various DSi-specific functionality. One of the "unknown" values could be the SD slot, but since these were reverse-engineered using DSiWare exploits, they couldn't be verified. Since we have full control of TWL_FIRM, that could be checked.

 

[Swiftloke]

Looks like we got a troll on our hands, boys.
But really, interesting thread. This might actually get somewhere...
If @dankzegriefer would get out of the thread.

 

[pbanj]

i will hand it to you this is the most thought out idea for ds stuff on the 3ds i have seen. it would be cool but i doubt it can/will happen

 

[GerbilSoft]

A theoretical RedTWL could be done in three phases:

1. Full NAND redirection. Redirect the TWL partition to the existing EmuNAND/RedNAND's TWL partition. Easiest to do, though it still requires reverse-engineering the NAND access code in TWL_FIRM. This would allow for running DSiWare from EmuNAND without installing to SysNAND.
2. File-based NAND redirection. (This is similar to cIOS EmuNAND on Wii.) You'd have a directory sdmc:/TWL_NAND/ that's basically the file structure from the TWLN partition. Requires hooking into the FAT filesystem code of TWL_FIRM and replacing NAND accesses with sdmc:/ accesses, plus a custom installer to install DSiWare games in sdmc:/TWL_NAND/ instead of the NAND partition.
3. DS ROM patching. Since DS games access Slot1 directly, and don't necessarily have a defined file system, you'd have to load the NDS9/NDS7 executables into RAM and then patch all of the SDK Slot1 accesses. This is similar to what DIOS MIOS and Nintendont do (patching DI access), and of course, it's the most time-consuming and difficult out of all three phases.

Sidenote: I don't have that much experience with ARM assembly, let alone reverse-engineering the TWL_FIRM executable, but I do have fairly good experience with low-level programming.

 

[zhdarkstar]

Thank you @GerbilSoft for actually taking the time to add thoughtful insight into the topic instead of just hurling vitriol. I never once claimed to have the knowledge to actually know how any of this worked. In fact, I outright stated in the OP that I wanted to be corrected if I was wrong about and told the proper information.

The whole DS launcher post was mostly a knee-jerk reaction to the whole "DS NEVAR!" attitude of the post I replied to. Sifting through 3dbrew to see exactly what steps the 3DS takes when shifting into DSi mode is rather confusing. The reason I even mentioned being able to harness the ARM11 was because I was envisioning an implementation similar to Nintendont, where we're essentially running the backwards-compatible software (DS in this case) while not truly exiting the native mode of the console. Theoretically, a way to run DS software while in 3DS mode would still have access to 3DS mode system resources. If I'm wrong, then I gladly accept it and would like to be shown where my logic fails.

But, that's getting slightly off-subject and was not the originally envisioned purpose of RedTWL. Phases 1 & 2 of your post are pretty much what I was thinking of when coming up with the idea. RedTWL would be a way to run DSiWare without having to install it to SysNAND nor be limited in capacity size to the amount of space that Nintendo designed the 3DS with. If any of the breakthroughs discovered along the way can somehow contribute to a DS rom loader, that would be a fortuitous-but-unintended result of RedTWL. To refer back to my label of "endgame CFW development," DS rom loading would be considered the endgame of the endgame. Too many pieces of the puzzle would have to come together to make it work, so it's best to not even focus on it until we can actually make the individual puzzle pieces themselves. Putting the carriage before the horse gets us nowhere.

 

[dankzegriefer]

k,

Looks like we got a troll on our hands, boys.
But really, interesting thread. This might actually get somewhere...
If @dankzegriefer would get out of the thread.

I'm a troll because I disagree with you? Okay, that makes sense, total sense, that isn't the dumbest statement I've heard in a LONG time. /s

--------------------- MERGED ---------------------------

Thank you @GerbilSoft for actually taking the time to add thoughtful insight into the topic instead of just hurling vitriol. I never once claimed to have the knowledge to actually know how any of this worked. In fact, I outright stated in the OP that I wanted to be corrected if I was wrong about and told the proper information.

The whole DS launcher post was mostly a knee-jerk reaction to the whole "DS NEVAR!" attitude of the post I replied to. Sifting through 3dbrew to see exactly what steps the 3DS takes when shifting into DSi mode is rather confusing. The reason I even mentioned being able to harness the ARM11 was because I was envisioning an implementation similar to Nintendont, where we're essentially running the backwards-compatible software (DS in this case) while not truly exiting the native mode of the console. Theoretically, a way to run DS software while in 3DS mode would still have access to 3DS mode system resources. If I'm wrong, then I gladly accept it and would like to be shown where my logic fails.

But, that's getting slightly off-subject and was not the originally envisioned purpose of RedTWL. Phases 1 & 2 of your post are pretty much what I was thinking of when coming up with the idea. RedTWL would be a way to run DSiWare without having to install it to SysNAND nor be limited in capacity size to the amount of space that Nintendo designed the 3DS with. If any of the breakthroughs discovered along the way can somehow contribute to a DS rom loader, that would be a fortuitous-but-unintended result of RedTWL. To refer back to my label of "endgame CFW development," DS rom loading would be considered the endgame of the endgame. Too many pieces of the puzzle would have to come together to make it work, so it's best to not even focus on it until we can actually make the individual puzzle pieces themselves. Putting the carriage before the horse gets us nowhere.

No, you're right, but I doubt it would work properly, due to having a different processor, and if emulated it would run incredibly slow.

 

[Wolfvak]

A theoretical RedTWL could be done in three phases:

1. Full NAND redirection. Redirect the TWL partition to the existing EmuNAND/RedNAND's TWL partition. Easiest to do, though it still requires reverse-engineering the NAND access code in TWL_FIRM. This would allow for running DSiWare from EmuNAND without installing to SysNAND.
2. File-based NAND redirection. (This is similar to cIOS EmuNAND on Wii.) You'd have a directory sdmc:/TWL_NAND/ that's basically the file structure from the TWLN partition. Requires hooking into the FAT filesystem code of TWL_FIRM and replacing NAND accesses with sdmc:/ accesses, plus a custom installer to install DSiWare games in sdmc:/TWL_NAND/ instead of the NAND partition.
3. DS ROM patching. Since DS games access Slot1 directly, and don't necessarily have a defined file system, you'd have to load the NDS9/NDS7 executables into RAM and then patch all of the SDK Slot1 accesses. This is similar to what DIOS MIOS and Nintendont do (patching DI access), and of course, it's the most time-consuming and difficult out of all three phases.

Sidenote: I don't have that much experience with ARM assembly, let alone reverse-engineering the TWL_FIRM executable, but I do have fairly good experience with low-level programming.

1- We don't even know whether TWL_FIRM is the one responsible for this. Maybe the DSi games themselves have hardcoded offsets for TWL NAND, which would require DSiWare patching. And trust me, emunand patches aren't the 'Easiest to do'. They require complex modifications, and even then we can't make sure it works.

2- File-based NAND redirection is simply impossible, due to the way FAT filesystems work. The furthest you may be able to get is to redirect all fs read/write operations to SD card with a specific offset (say, a file called TWLN.bin for instance). *Maybe* you can recreate the entire FAT filesystem with simple files, but other than that this is pure bullshit, due to the fact that we can't write a TWL_FIRM from scratch (yet).

3- This is hard, but we know it's possible. Maybe not patching, but we know that it's perfectly possible for DS games to be converted to DSiWare, due to AWDOR and most recently WarioWare: Touched!. BTW, the ARM9 is the one which accesses the SD card while on CTR mode, but the ARM7 is the one that does the job while on TWL mode. Keep that in mind.