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

  • Thread starter Thread starter Wolfvak
  • Start date Start date
  • Views Views 331,603
  • Replies Replies 1,434
  • Likes Likes 75
Status
Not open for further replies.
Iquickly played with it before going to work.

Top Screen :
1458818266-top-output.gif


Bottom Screen :
1458818330-bottom-output.gif


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 :grog:
YESS! THANK YOU!
 
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.
 
My fork of A9LH doesnt actually show anything until it boots into my home menu, can I still use this?
 
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...
 
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?
 
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.
 
  • Like
Reactions: LuigiXL
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.
 
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
 
Last edited by Wolfvak,
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.
 
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!)
 
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 :P
 
  • Like
Reactions: 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:
Code:
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
 
Last edited by RednaxelaNnamtra,
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:
Code:
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...
 
Last edited by Wolfvak,
Status
Not open for further replies.

Site & Scene News

Popular threads in this forum