Homebrew [RELEASE] BootAnim9 - Custom boot animations for your 3DS!

[mgrev]

Iquickly played with it before going to work.

Top Screen :

Bottom Screen :

The top screen in in french, I will make an english one later, time to go to work.

@Wolfvak : I have a request : can you make a version whith screens init black instead of white, it will be more seamless for contributions like mine for example. Great work btw, thx for the release

YESS! THANK YOU!

 

[Wolfvak]

Alright, I'm back and I made some changes:

- Changed white screen to black (dumb mistake during development)
- Moved animations to their own folder ('anim' folder on SD root)
- Removed fixed framerate, now defined by a hex value on 'sdmc:/anim/config'
- Both animations *HAVE* to have the same framerate until I get multithreading or something, which ain't gonna happen soon.

Gonna upload my work to GitHub in a couple of hours or so.

 

[LuigiXL]

My fork of A9LH doesnt actually show anything until it boots into my home menu, can I still use this?

 

[Wolfvak]

My fork of A9LH doesnt actually show anything until it boots into my home menu, can I still use this?

What? You mean it doesn't perform screen initialization like the current one does? Maybe I'll *try* to implement that as well...

 

[LuigiXL]

What? You mean it doesn't perform screen initialization like the current one does? Maybe I'll *try* to implement that as well...

I have two A9LH systems, one does screen init, the other simply boots (i am using aurei/sysnand o3ds for the one that doesnt, and an emunand on the one that does screen init) I have no idea why they differ but apparently the fork it used?

 

[Wolfvak]

I have two A9LH systems, one does screen init, the other simply boots (i am using aurei/sysnand o3ds for the one that doesnt, and an emunand on the one that does screen init) I have no idea why they differ but apparently the fork it used?

Yeah, you *most likely* used @delebile's old fork which doesn't include screen init. You could use @dark_samus3' installer, but I'll try to include screen init here as well.

 

[LuigiXL]

Yeah, you *most likely* used @delebile's old fork which doesn't include screen init. You could use @dark_samus3' installer, but I'll try to include screen init here as well.

Thanks, i dont want to go off-topic but could i use the new fork with my existing setup?

 

[Wolfvak]

Alright, latest build is up! https://github.com/Wolfvak/BootAnim9/releases

Doesn't include screen init, working on it and on looping the animations.

 

[LuigiXL]

Alright, latest build is up! https://github.com/Wolfvak/BootAnim9/releases

Doesn't include screen init, working on it and on looping the animations.

Great!! Working here

If anyone could make an 8-bit Mario or Luigi one that would be amazing!

 

[RednaxelaNnamtra]

JPEG decompression actually introduces an incredible (literally, I couldn't believe it) amount of processing, something the ARM9 doesn't have. A JPEG stream would only decrease file size, but not improve performance (in any case, it makes it worse)
On the other hand, we (at least I) can't access any sound features from the ARM9 chip... yet

Maybe you could make a payload for the arm11, which runs the animation. This way you would have at least twice as much processing power(268MHz in arm11 instead of 134MHz on arm9). You would only need to use arm9 to load the file, because arm11 has no direct file access.

 

[Wolfvak]

Maybe you could make a payload for the arm11, which runs the animation. This way you would have at least twice as much processing power(268MHz in arm11 instead of 134MHz on arm9). You would only need to use arm9 to load the file, because arm11 has no direct file access.

Unfortunately such thing would defeat the whole purpose of *boot* screens, they're supposed to come up as soon as you boot up your console.
Besides, I'd have to program an entire firm to access the ARM11 AFAIK, there's no way to access it from A9LH.
The closest thing I can imagine would be to boot a minimal Linux distro that simply shows you the boot screen, sets some sort of flag and reboots. This time the loader knows it's been rebooted so it just chainloads to arm9payload.bin

 

[RednaxelaNnamtra]

Unfortunately such thing would defeat the whole purpose of *boot* screens, they're supposed to come up as soon as you boot up your console.
Besides, I'd have to program an entire firm to access the ARM11 AFAIK, there's no way to access it from A9LH.

No, you would only need to start loading the file to a specific location in fc ram, while arm11 loads it from there, you would only need a simple communication, and if you checked out the screen init code(which also runs on arm11) you would see that its not that hard to write a payloads that's running at arm11. The only thing would be, that you would need to write something to communicate for the file access, so it would wait If the file loading on arm9 is to slow.

 

[Wolfvak]

No, you would only need to start loading the file to a specific location in fc ram, while arm11 loads it from there, you would only need a simple communication, and if you checked out the screen init code(which also runs on arm11) you would see that its not that hard to write a payloads that's running at arm11. The only thing would be, that you would need to write something to communicate for the file access, so it would wait If the file loading on arm9 is to slow.

I actually already load stuff onto the FCRAM, hence the 50MB limitation.
Doing multi-cpu stuff is a pain, so I just limited myself to the ARM9.
Besides, these are supposed to not be any longer than 5 seconds or so, it's just a little extra for the people who love customization (like me!)

 

[Aurora Wright]

No, you would only need to start loading the file to a specific location in fc ram, while arm11 loads it from there, you would only need a simple communication, and if you checked out the screen init code(which also runs on arm11) you would see that its not that hard to write a payloads that's running at arm11. The only thing would be, that you would need to write something to communicate for the file access, so it would wait If the file loading on arm9 is to slow.

Just load the thing to fcram on arm9 and then have the arm11 process it. fcram is 128 MB

 

[Wolfvak]

Just load the thing to fcram on arm9 and then have the arm11 process it. fcram is 128 MB

Alright, I'll try it out. Can you just return; from the ARM11 payload to the ARM9?

 

[RednaxelaNnamtra]

Alright, I'll try it out. Can you just return; from the ARM11 payload to the ARM9?

On arm9 simply wait for an value, which you set on arm11 after you finished, and on arm11 end the execution with something like this:

volatile u32 *a11_entry = (volatile u32 *)0x1FFFFFF8;
while (!*a11_entry);
((void (*)())*a11_entry)();

you would also need to set the a11_entry to 0 in your arm11 code, before you do the while.
But keep in mind that you should not overwrite your own code in FCRAM

 

[Wolfvak]

On arm9 simply wait for an value, which you set on arm11 after you finished, and on arm11 end the execution with something like this:

volatile u32 *a11_entry = (volatile u32 *)0x1FFFFFF8;
while (!*a11_entry);
((void (*)())*a11_entry)();

you would also need to set the a11_entry to 0 in your arm11 code, before you do the while.
But keep in mind that you should not overwrite your own code in FCRAM

Alright I checked out a9lh's source and I think I can do it. Expect something in <12 hours

EDIT: Now that I think about it, I might as well move all decompression code to the ARM11 and just signal the ARM9 which location and size it should copy to framebuffer.
Would that work...? Because it appears the ARM9 is still active, as far as I can tell...

 

[Chaos Cat]

@Wolfvak Im assuming there is a file length limit also raw .rgb files hows the 3ds handle the framerate?




im assuming it replace splash

for sure your a splash

 

[Mr.ButtButt]

do you think sound'll ever make it's way to these?
If not, I can understand, but that would be sweet

 

[MajinCubyan]

Pretty awesome! Reminds me of the hayday of the psp scene.