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?).
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.
3D bug fixed?I got the screeninit version.
It's not going to be added to the installer yet because it has some cleaning up to do.
Working on it. I think it's fixed but haven't tested.3D bug fixed?
How was it solved?Working on it. I think it's fixed but haven't tested.


screen init stands for screen initialization and we can get coding to work before our cfw starts up, like how cakes has it's patch menu that pops up before we boot into cfw.What is screen init and what can we use it for
How much does the screen init delay the boot times?I got the screeninit version.
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?screen init stands for screen initialization and we can get coding to work before our cfw starts up, like how cakes has it's patch menu that pops up before we boot into cfw.
As long as the parts of the nand that have A9LH aren't brokenAhh 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.Ahh so it would allow for things like downgrade with both emunand and sysnand bricked?
you can dump and flash nands and i think some full partitions. but decrypting and injecting files is what doesnt workwell 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.
How much does the screen init delay the boot times?
Will the backlight turn on much faster then?It should be negligible. Setting registers takes nearly no CPU time at all (though waiting for hardware to turn on might take a tiny bit longer).

from what I was told that didn't work quite yet but something was being worked onyou can dump and flash nands and i think some full partitions. but decrypting and injecting files is what doesnt work
Will the backlight turn on much faster then?