Homebrew ARM9Loader -- Technical Details and Discussion

  • Thread starter Thread starter Selver
  • Start date Start date
  • Views Views 579,621
  • Replies Replies 4,025
  • Likes Likes 42
Yeah, I read al9h boots the payload so early the screen didn't even init yet. No idea why people want to reintroduce the bug by getting screen init (unless we are fixing it in the process?).

So boot managers (and also CakesFW) can work. I'm sure the screen init process is reversible (if it wasn't, services like gsp::Lcd on the 3DS OS wouldn't be able to turn the screens on and off), it's just a matter of figuring out how to do it, if different values are needed.
 
wtf ? what brick protection ? which d9 ?

Absolutely not... We trade the little 3D bug (that can be fixed by closing the lid for some seconds) on N3DS for a screen init from a9lhax, which means we can have for example the CakesFW menu from arm9loaderhax.

And this isn't released yet.

Thank for confirming my beliefs.

I hope a branch of a9lhax is created for New3ds that doesn't have screen init (that is until a time comes when when the 3d bug can be fixed without us having to close the lid for some seconds)
 
Last edited by democracy,
I got the screeninit version. :P
It's not going to be added to the installer yet because it has some cleaning up to do.
 
Ahh so it would allow for things like downgrade with both emunand and sysnand bricked?
well right now if we tried getting D9 to run at screen init all that would happen is having a useless menu as we wouldn't be able to dump out sysnand or emunand bin files from what I understand.
 
well right now if we tried getting D9 to run at screen init all that would happen is having a useless menu as we wouldn't be able to dump out sysnand or emunand bin files from what I understand.
you can dump and flash nands and i think some full partitions. but decrypting and injecting files is what doesnt work
 

Site & Scene News

Popular threads in this forum