Homebrew DS(i) Mode hacking progress thread

hacksn5s4 · Feb 6, 2016

i know theres unused code for dumping roms but can a dumping roms feature be added to twl or a romdumping app be made

DigitalJosee · Feb 6, 2016

smealum said:
- snip -

Now that's what I call progress

Hiccup · Feb 6, 2016

hacksn5s4 said:
i know theres unused code for dumping roms but can a dumping roms feature be added to twl or a romdumping app be made

try injecting wooddumper

hacksn5s4 · Feb 6, 2016

Hiccup said:
try injecting wooddumper

how do i inject that

Normmatt · Feb 6, 2016

smealum said:
just saw this thread. i looked into twl mode with some custom debugging hardware a while back for reasons and i should have a bunch of notes somewhere but the gist of what might be relevant off the top of my head is :

- you can totally make it load your own roms relatively easily if you want to, for example by editing twl_bg, the background process that runs on the arm11...
- ...but that's more or less limited to homebrew. basically the problem remains that the game will try to access data from a non-existant gamecard. you could potentially force it to run in twl instead of ntr and redirect rom and save to sd or nand, it the game might not even run due to some funky memory mapping differences. (something to do with mirrors iirc)
- even with legit games, you're pretty limited in terms of what improvements you could make to the twl_form experience. basically switching into twl mode completely disconnects the arm11 (the only thing running 3ds mode code at that point) from fcram, which is where most (?) twl memory lives. I tried but failed to bring that bus back up. so basically arm11 can't affect twl stuff : can't edit memory, can't control execution in any way (in fact, hitting home doesn't even pause execution iirc)
- the arm11 is responsible for fetching the DS frame buffers from lgyfb and displaying it. so you can totally change the way it does that, apply some post processing to that if you're into that, but that's basically it. I have some documentation on lgyfb, but the gist of it is there's some configuration for the upscale filter, and then it uses smea to fetch the actual data.

not sure if this information will be useful to anyone, but I figured posting it wouldn't hurt.

Wait the arm11 uses SMEA to fetch the actual data? How does one make the arm11 do such magic?

Fatalanus · Feb 6, 2016

This thread is interesting.
Please, can someone try to explain what the legendary Smea said, but with simple words?

Coto · Feb 6, 2016

Fatalanus said:
This thread is interesting.
Please, can someone try to explain what the legendary Smea said, but with simple words?

the guy called smea has said:

twl uses somewhat the mirrored ram addressing found on nds memory layout (see problemkaputt) , except its for dsi mode. And most ARM11 is left doing render from framebuffer to gpu job

smealum · Feb 6, 2016

Normmatt said:
Wait the arm11 uses SMEA to fetch the actual data? How does one make the arm11 do such magic?

lol that should have been DMA. i wrote this on my phone and for some reason it knows smea but not DMA i guess.

Jiro2 · Feb 6, 2016

smealum said:
basically the problem remains that the game will try to access data from a non-existant gamecard.

So what if you do use a gamecard?

How does a DS flashcart gain permission to run DS games? Could you hack the TWL_FIRM so that anything you put in automatically gets DSi permissions even if it just asks for DS permissions, then be able to use a DS flashcart for DSi games? (Would DSi encryption mess this up?)

dubbz82 · Feb 6, 2016

Jiro2 said:
So what if you do use a gamecard?

How does a DS flashcart gain permission to run DS games? Could you hack the TWL_FIRM so that anything you put in automatically gets DSi permissions even if it just asks for DS permissions, then be able to use a DS flashcart for DSi games?

A ds flash cart sends and receives data the same way as a standard ds cart does....it's not about gaining permission (comparatively, that's probably actually rather simple), it's about the actual data transmission. Even if we were to use a "dummy" cartridge, it'd be retrieving all sorts of invalid data. This isn't as easy of an issue to tackle as it might appear to be.

Fatalanus · Feb 6, 2016

so if I understand correctly, for now .cia of DS game is something that is highly compromised?

jaksy · Feb 6, 2016

smealum said:
so you can totally change the way it does that, apply some post processing to that if you're into that, but that's basically it. I have some documentation on lgyfb, but the gist of it is there's some configuration for the upscale filter

Perhaps I'm understanding this wrong, but are you saying in theory we might be able to sharpen the way the system outputs the DS image?
The default scaling the system uses looks like a very blurry bilinear style filter, which is rather ugly in my opinion, so that sounds like a somewhat useful concept.

Though if we're talking about scaling output being tweaked, I'd be much more interested in seeing the video issues fixed in agb_firm first.
Who the hell thought all that ghosting and blur was acceptable?

Jiro2 · Feb 6, 2016

dubbz82 said:
A ds flash cart sends and receives data the same way as a standard ds cart does....it's not about gaining permission (comparatively, that's probably actually rather simple), it's about the actual data transmission. Even if we were to use a "dummy" cartridge, it'd be retrieving all sorts of invalid data. This isn't as easy of an issue to tackle as it might appear to be.

Could you at least hack it so that all DSi games always get all permissions, then use an iEvolution to run a DSi game? The iEvolution uses the Cooking Coach exploit and only has the permissions that Cooking Coach has; having all permissions would be an improvement.

smealum · Feb 6, 2016

jaksy said:
Perhaps I'm understanding this wrong, but are you saying in theory we might be able to sharpen the way the system outputs the DS image?
The default scaling the system uses looks like a very blurry bilinear style filter, which is rather ugly in my opinion, so that sounds like a somewhat useful concept.

Though if we're talking about scaling output being tweaked, I'd be much more interested in seeing the video issues fixed in agb_firm first.
Who the hell thought all that ghosting and blur was acceptable?

100% possible, not even very hard. not sure (dont remember) if LGYFB's builtin filtering method would allow that directly (i suspect it would), but even if not you could just grab the original framebuffer and upscale it with the GPU. (twl_bg already uses the 3DS's GPU to render to DS mode framebuffer, so at that point it's just a matter of changing texture settings to nearest pixel and scale factor)

jaksy · Feb 6, 2016

smealum said:
100% possible, not even very hard. not sure (dont remember) if LGYFB's builtin filtering method would allow that directly (i suspect it would), but even if not you could just grab the original framebuffer and upscale it with the GPU. (twl_bg already uses the 3DS's GPU to render to DS mode framebuffer, so at that point it's just a matter of changing texture settings to nearest pixel and scale factor)

Absolutely fascinating.
And here I thought this topic was just going to be everyone talking in circles for 17 pages, but it turns out there may be something of merit to this discussion after all.

If this kind of tweaking to output is as simple as you're indicating then it definitely warrants some looking into from the community.
Unfortunately I'm a bit out of my depth here as I'm not even sure what this LGYFB (Framebuffer perhaps?) is you're referencing, since I can't find any other usages of that acronym on google or gbatemp.
You mention having notes or documents on it, anything helpful you can release that might point us in the right direction for researching this?

Also if twl_bg is the process that handles the arm11 instructions in twl_firm, is there a similar process governing it for agb_firm?

AtlasFontaine · Feb 6, 2016

smealum said:
100% possible, not even very hard. not sure (dont remember) if LGYFB's builtin filtering method would allow that directly (i suspect it would), but even if not you could just grab the original framebuffer and upscale it with the GPU. (twl_bg already uses the 3DS's GPU to render to DS mode framebuffer, so at that point it's just a matter of changing texture settings to nearest pixel and scale factor)

Out of curiosity, is possible to modify the AGB_FIRM to delete the motion blur and add more contrast?

Billy Acuña · Feb 6, 2016

smealum said:
just saw this thread. i looked into twl mode with some custom debugging hardware a while back for reasons and i should have a bunch of notes somewhere but the gist of what might be relevant off the top of my head is :

- you can totally make it load your own roms relatively easily if you want to, for example by editing twl_bg, the background process that runs on the arm11...
- ...but that's more or less limited to homebrew. basically the problem remains that the game will try to access data from a non-existant gamecard. you could potentially force it to run in twl instead of ntr and redirect rom and save to sd or nand, it the game might not even run due to some funky memory mapping differences. (something to do with mirrors iirc)
- even with legit games, you're pretty limited in terms of what improvements you could make to the twl_form experience. basically switching into twl mode completely disconnects the arm11 (the only thing running 3ds mode code at that point) from fcram, which is where most (?) twl memory lives. I tried but failed to bring that bus back up. so basically arm11 can't affect twl stuff : can't edit memory, can't control execution in any way (in fact, hitting home doesn't even pause execution iirc)
- the arm11 is responsible for fetching the DS frame buffers from lgyfb and displaying it. so you can totally change the way it does that, apply some post processing to that if you're into that, but that's basically it. I have some documentation on lgyfb, but the gist of it is there's some configuration for the upscale filter, and then it uses its own DMA engine to fetch the actual data.

not sure if this information will be useful to anyone, but I figured posting it wouldn't hurt.

Ohh my...!!!

Billy Acuña · Feb 6, 2016

jaksy said:
Also if twl_bg is the process that handles the arm11 instructions in twl_firm, is there a similar process governing it for agb_firm?

Obviously

jaksy · Feb 6, 2016

Billy Acuña said:
Obviously

That's not really helpful. What I'm asking is if agb_firm's arm11 access is governed by the same process or a unique one, and if so what it's name would be.

Billy Acuña · Feb 7, 2016

OP UPDATED!!!
Thank you so much @smealum for seeing this post!!!

Homebrew DS(i) Mode hacking progress thread

Banned!

Go your clever boy, and remember me!

Well-Known Member

Banned!

Former AKAIO Programmer

Well-Known Member

-

growing up sucks.

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

growing up sucks.

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Similar threads

Popular threads in this forum