Homebrew Official [Release] GodMode9 - All Access File Browser for the 3DS

[Kazuma77]

wont boot
i dont really use my a9lh system much so im gona have to look for the file
lots of sd cards -_-

OK. I think I know what it is. Apparently part of BootCTR9 is staying in memory even when shutting the system off briefly. I tried it straight from the bootmenu after the system had been off for a while, and sure enough, it didn't work. @d0k3: converted payloads ARE in fact broken on the bootloader. I tried all of my personal daily builds back to 1.4.2 stable and none of them will load Gateway or even AGBSave9. SALTMODE still provides a great deal of flexibility that vanilla B9S does not. And it doesn't seem any slower than B9S, so, continuing to use it with BootCTR9 isn't going to hurt me any. But it would be even better if it ran GW. I've got too many ROMs to stop using it just because the fascist "follow the guide" hypetrain says I should.

I think it's worth adding uncompressed zip extraction even without mounting. In installing ntrboot, it's okay to use FAT image or RomFS. but almost everyone have installed 7-zip on their computer. but not about software for making FAT Image/RomFS. (I also have not installed one for FAT Image)
On github, the issue about zip extracting is opened three times. It means everyone want to extract zip file on GodMode9 and I don't think they stick to extract compressed one. Making uncompressed zip file is very easy.
You can add extract zip at least then please add.

You have a point there. Not many people are going to have a FAT image maker (ISO, maybe, FAT, not so much). I think what d0k3 is primarily concerned about is noobs trying to extract compressed zip files and all of the "it's not working" posts that would pop up when it didn't work. That people's eyes will latch onto that word "unzip" and skip right over the word "uncompressed" next to it. But maybe if he were to only implement it as a scripting command, and not a context function, much of that could be prevented. I'm still not sure if it will make much difference. I should time both methods, going both ways, with Freewatch.

 

[Deleted User]

is the bootloader able to load from the nand?

 

[Deleted User]

OK. I think I know what it is. Apparently part of BootCTR9 is staying in memory even when shutting the system off briefly. I tried it straight from the bootmenu after the system had been off for a while, and sure enough, it didn't work. @d0k3: converted payloads ARE in fact broken on the bootloader. I tried all of my personal daily builds back to 1.4.2 stable and none of them will load Gateway or even AGBSave9. SALTMODE still provides a great deal of flexibility that vanilla B9S does not. And it doesn't seem any slower than B9S, so, continuing to use it with BootCTR9 isn't going to hurt me any. But it would be even better if it ran GW. I've got too many ROMs to stop using it just because the fascist "follow the guide" hypetrain says I should.

its somewhat working for me now
loads stuff fine but sometimes freezes with a9lh payloads

 

[Kazuma77]

OK. Numbers time for the unzip routine.

normal copy process:
copy to RAM: 57.70
copy from RAM: 1:31.70
total: 2:29.40

zip copy process:
copy to RAM: 17.26
unzip from RAM: 1:54.00
total: 2:11.26

difference: 18.14

So, yes, it is a little bit faster overall. But not nearly as much as I was expecting. The extraction overhead was a bit more severe than I was expecting.

its somewhat working for me now
loads stuff fine but sometimes freezes with a9lh payloads

Which version of BootCTR9 are you using? The one at the bottom of page 3 seems to have the best compatibility (the newer versions can't run D9 for some reason -- I don't use it as often as I used to, but I do still use it occasionally).

 

[d0k3]

OK. I think I know what it is. Apparently part of BootCTR9 is staying in memory even when shutting the system off briefly. I tried it straight from the bootmenu after the system had been off for a while, and sure enough, it didn't work. @d0k3: converted payloads ARE in fact broken on the bootloader. I tried all of my personal daily builds back to 1.4.2 stable and none of them will load Gateway or even AGBSave9. SALTMODE still provides a great deal of flexibility that vanilla B9S does not. And it doesn't seem any slower than B9S, so, continuing to use it with BootCTR9 isn't going to hurt me any. But it would be even better if it ran GW. I've got too many ROMs to stop using it just because the fascist "follow the guide" hypetrain says I should.

These old payloads assume the framebuffer to be at a certain instead of VRAM. Bringing back the old framebuffer for compatibility reasons would introduce other problems, so that's out of question. Now, there may be solution to this. If you got access to the code, you could just replace the framebuffer addresses with new ones. If not... maybe some patcher can be made that would handle this, alternatively a universal preloader for those old payloads.

 

[Kazuma77]

These old payloads assume the framebuffer to be at a certain instead of VRAM. Bringing back the old framebuffer for compatibility reasons would introduce other problems, so that's out of question. Now, there may be solution to this. If you got access to the code, you could just replace the framebuffer addresses with new ones. If not... maybe some patcher can be made that would handle this, alternatively a universal preloader for those old payloads.

Well, 3 of the 4 converted payloads I use are on Github. But the chances of GW handing me their source are between slim and none. So, unless it can be changed with a hex editor, it will take a preloader for that. Still, what would I look for in the case of the other 3 then? I might as well try to get those working.

 

[d0k3]

Well, 3 of the 4 converted payloads I use are on Github. But the chances of GW handing me their source are between slim and none. So, unless it can be changed with a hex editor, it will take a preloader for that. Still, what would I look for in the case of the other 3 then? I might as well try to get those working.

Hmm... @Wolfvak - can you give a hand there? Also, all you'll get from team GW is a f...you, I guess. It may be possible to change it by just search and replace in a hex editor.

 

[Kazuma77]

Hmm... @Wolfvak - can you give a hand there? Also, all you'll get from team GW is a f...you, I guess. It may be possible to change it by just search and replace in a hex editor.

Actually, I just had an idea. If you could add the option to boot the other firm partition to the bootloader, I could recompile B9S 1.0 to launch a different file (maybe "oldboot.firm" or something).

 

[d0k3]

Actually, I just had an idea. If you could add the option to boot the other firm partition to the bootloader, I could recompile B9S 1.0 to launch a different file (maybe "oldboot.firm" or something).

Hmm... did that stuff still work in B9S 1.0? Also, we can't chainload B9S. It's really not possible, because of the exploit it uses.

 

[The Catboy]

You can chainload gm9 into Luma3DS and then chainload into the converted payloads that way. That should in theory be a workaround for this situation.

 

[Kazuma77]

Hmm... did that stuff still work in B9S 1.0? Also, we can't chainload B9S. It's really not possible, because of the exploit it uses.

I never ran 1.0, but from what everyone else is saying, it used the old framebuffer location. I was just thinking, firm1 is just sitting there doing nothing. But I can just keep using BootCTR9 if there's no way to use it.

You can chainload gm9 into Luma3DS and then chainload into the converted payloads that way. That should in theory be a workaround for this situation.

I think you mean BootCTR9. Yeah it works. Or if you want a menu, you can have CBM9 patch BootCTR9 to use a separate .ini file per payload. It just seems wasteful having two chainloaders, but, it certainly provides more flexibilty having one on the firm partition. You can launch ReiNAND as boot.firm and still be able to run other things, for example. I guess it's not like it adds anything to my boot time, though (nothing noticeable, anyway).

EDIT: Actually, that works. A copy of CBM9 in the "gm9/payloads" folder named "Converted.firm" that has the converted payloads (on a configuration file appropriately named cbm9_converted.cfg).

 

[The Catboy]

I never ran 1.0, but from what everyone else is saying, it used the old framebuffer location. I was just thinking, firm1 is just sitting there doing nothing. But I can just keep using BootCTR9 if there's no way to use it.



I think you mean BootCTR9. Yeah it works. Or if you want a menu, you can have CBM9 patch BootCTR9 to use a separate .ini file per payload. It just seems wasteful having two chainloaders, but, it certainly provides more flexibilty having one on the firm partition. You can launch ReiNAND as boot.firm and still be able to run other things, for example. I guess it's not like it adds anything to my boot time, though (nothing noticeable, anyway).

Regardless of whatever chainloading method you want to use, my theory should still hold up.
I personally don't use the converted payloads as I just see them as outdated. If the dev didn't update them to work with B9S (or gm9 in this case,) then I don't use them.

 

[Wolfvak]

Well, 3 of the 4 converted payloads I use are on Github. But the chances of GW handing me their source are between slim and none. So, unless it can be changed with a hex editor, it will take a preloader for that. Still, what would I look for in the case of the other 3 then? I might as well try to get those working.

If you tell me exactly which programs they are, I guess I could fix them up to work on B9S. As long as they're sanely coded and just have a small number of broken assumptions (framebuffers, ARM11 issues, etc).

 

[Kazuma77]

If you tell me exactly which programs they are, I guess I could fix them up to work on B9S. As long as they're sanely coded and just have a small number of broken assumptions (framebuffers, ARM11 issues, etc).

Well, the main one would have to be Puma33DS. I don't know why, but it seems to be more stable with Spectre3DS and CTRHexenII than Luma Legacy (that surprises me, because my whole reason for doing a custom compile of Legacy that changes the folder to "legacy" was to have a better and more up to date *hax runner than Puma).

The second one is AGBSave9. It's of no importance to me personally. I have a DSTwo. I don't use GBA injects at all. But for the sake of completion I include it in my AIO, because while it's just a hack of D9, it does cut straight to the chase if you just want to quickly backup a save. I figure some people might find it handy.

The third one is EmuNAND9. I really wouldn't worry about it too much. I converted it just because it can create a legacy EmuNAND (and that seems to have maximum CFW compatibility -- Rei and Cakes hate minimums). However, I've had issues with NAND partitions not even showing up correctly in GM9, so, I'm not even sure I want to keep it at this point.

I was really hoping this was something I could learn how to do, but I have no coding experience, so, if it's something complicated, I'll just let you take care of it, I guess. Thanks in advance.

 

[Wolfvak]

Well, the main one would have to be Puma33DS. I don't know why, but it seems to be more stable with Spectre3DS and CTRHexenII than Luma Legacy (that surprises me, because my whole reason for doing a custom compile of Legacy that changes the folder to "legacy" was to have a better and more up to date *hax runner than Puma).

The second one is AGBSave9. It's of no importance to me personally. I have a DSTwo. I don't use GBA injects at all. But for the sake of completion I include it in my AIO, because while it's just a hack of D9, it does cut straight to the chase if you just want to quickly backup a save. I figure some people might find it handy.

The third one is EmuNAND9. I really wouldn't worry about it too much. I converted it just because it can create a legacy EmuNAND (and that seems to have maximum CFW compatibility -- Rei and Cakes hate minimums). However, I've had issues with NAND partitions not even showing up correctly in GM9, so, I'm not even sure I want to keep it at this point.

I was really hoping this was something I could learn how to do, but I have no coding experience, so, if it's something complicated, I'll just let you take care of it, I guess. Thanks in advance.

For the last two, just use GM9. I know I might sound like a broken record, but honestly, @d0k3, me and a ton of other people have worked our asses off trying to get a good AIO tool up and running in pretty much every environment available, and the changes done are too great to backport to E9.

As for Puma33DS, it should be doable. It's just a matter of managing the framebuffers and the ARM11 entrypoint.

 

[windows_server_2003]

You have a point there. Not many people are going to have a FAT image maker (ISO, maybe, FAT, not so much). I think what d0k3 is primarily concerned about is noobs trying to extractt compressed zip files and all of the "it's not working" posts that would pop up when it didn't work. That people's eyes will latch onto that word "unzip" and skip right over the word "uncompressed" next to it. But maybe if he were to only implement it as a scripting command, and not a context function, much of that could be prevented. I'm still not sure if it will make much difference. I should time both methods, going both ways, with Freewatch.

so should change descriotion to like this?

added "unzip" command for extract UNCOMPRESSED zip files. Cannot extract compressed ones.

I don't think there are many people who skip "UNCOMPRESSED" .

 

[Kazuma77]

For the last two, just use GM9. I know I might sound like a broken record, but honestly, @d0k3, me and a ton of other people have worked our asses off trying to get a good AIO tool up and running in pretty much every environment available, and the changes done are too great to backport to E9.

As for Puma33DS, it should be doable. It's just a matter of managing the framebuffers and the ARM11 entrypoint.

Well, GM9 is more than good. It's frigging awesome. If it wasn't for GM9, my AIO would not have even been possible. I don't call it InScripted for nothing. GM9 scripts are it's soul. That's fine. I wasn't really worried about those other two anyway.

EDIT: I came up with a solution in the meantime. Another copy of CBM9 with an altered configuration file name. I named it "Converted.firm" and did the BootCTR9 with patched .ini trick for Puma and GW. Not quite as good as launching them directly, but at least I have them working from the GM9 bootloader. I'll still take that Puma conversion if you still feel like doing it though. Less workarounds is good, and a proper might be even more stable.

EDIT2: Looks like Cakes isn't working either. I didn't even know it was converted until recently. It works just fine with CBM9, and even Luma only crashes with it the first time it is run with a specific firmware combo. Fixing this would help me even more than Puma -- I've got a "Cakes Launcher" SSR that uses "filesel" to pick a firmware to use with it. So this would be fixing two in one.

so should change descriotion to like this?

added "unzip" command for extract UNCOMPRESSED zip files. Cannot extract compressed ones.

I don't think there are many people who skip "UNCOMPRESSED" .

I don't know. I was just speculating as to why he might be hesitant to add it. For all I know it's the implementation. It's d0k3 you have to convince, not me. You wanted us to test it. I've posted my results. You did shave 18 seconds off my copy time. Granted that's with roughly 80 MB going back and forth. Anyone doing speed runs is not going to be using anywhere near that. Still, a few seconds is a few seconds. The only suggestion I have is that it might be nice to see the names of the files being extracted. It seems alright to me. But I'm no coder. I wouldn't know good clean code from sloppily written crap. And again, it's not my call.

Regardless of whatever chainloading method you want to use, my theory should still hold up.
I personally don't use the converted payloads as I just see them as outdated. If the dev didn't update them to work with B9S (or gm9 in this case,) then I don't use them.

That explains why you weren't aware that your solution doesn't work. Luma will NOT run a converted payload. It will crash with any of them. The solution for Luma is to hotkey BootCTR9 to the key you want, then define that same hotkey in the "boot_config.ini" file. Using CBM9 to launch BootCTR9 with the patching option to switch .ini files (the desired payload is always the default this way) turns out to be the best option for GM9's chainloader. It's working well.

 

[d0k3]

@Kazuma77 - AGBSAVE9 (and, for that matter, D9, too) has a different problem with dumping saves in that saves are not "wrong", but incompatible with common emulators *and* save patches. This has only been recently fixed in GM9, so GM9 really is the only tool that does it "proper". I use quotes for that because, well, proper is relative here - we're basically working around a messup that happened years ago. Regardless, the GM9 way of doing things is what you want.

I don't know. I was just speculating as to why he might be hesitant to add it. For all I know it's the implementation. It's d0k3 you have to convince, not me. You wanted us to test it. I've posted my results. You did shave 18 seconds off my copy time. Granted that's with roughly 80 MB going back and forth. Anyone doing speed runs is not going to be using anywhere near that. Still, a few seconds is a few seconds. The only suggestion I have is that it might be nice to see the names of the files being extracted. It seems alright to me. But I'm no coder. I wouldn't know good clean code from sloppily written crap. And again, it's not my call.

That's correct, I am hesitant to take the pull request, for several reasons. @windows_server_2003 - this is what keeps me from taking it. Some of it may be fixable, and I'm still considering, that's why I left it open.

• First and foremost, the question who this is useful for, for several reasons. In fact, this will not work with 99.999% of ZIP files found out in the wild (I'm not even exaggerating). The unzip command will also not work with the new vram0.img feature, cause ZIPs rely on their *footer*, which we can't provide access to here. You're correct in saying that far more people have 7z installed than OSFmount (for FAT images) or CTRtool (for RomFS), but then - who will have a use for filesystem containers? It's powerusers rather than regular ones, and that type of user can use CTRtool and do the same with an already supported format. The already opened feature requests were about *compressed* ZIP support, btw.
• The implementation is also an issue. I see you did pay attention regarding the write permissions system, but with stuff like that you do add more messup potential (at least on the side of devs). What should actually have been done is to provide mount support for ZIP files, than go through the regular way (mount, copy), so the already existing, tested functions can handle the write permissions. Instead, what we have here is in essence a new, specialized, copy function, handling it's own write permissions. If copying *all* files from a container at once is what you wanted to do, that is something that should better be done in a universal way, in the scripting system.
• Implementation issues continued... stuff in GM9 is meant to work out of the box, especially for users who followed the Quick Setup Guide. Stuff like this, for example, is not really intuitive to handle for the user, and makes the unzip feature feel very incomplete. It's somehow like if I did NitroFS support, but told users, no, NitroFS with folders is not supported, or requires user interaction.
• A smaller issue, but the coding style is not consistent with the remainder of the code (yeah, external libs used also have an inconsistent coding style). That doesn't mean your coding style is bad, it's just not consistent. there are also a lot of global vars used where I think should be much less.

 

[windows_server_2003]

@Kazuma77 - AGBSAVE9 (and, for that matter, D9, too) has a different problem with dumping saves in that saves are not "wrong", but incompatible with common emulators *and* save patches. This has only been recently fixed in GM9, so GM9 really is the only tool that does it "proper". I use quotes for that because, well, proper is relative here - we're basically working around a messup that happened years ago. Regardless, the GM9 way of doing things is what you want.



That's correct, I am hesitant to take the pull request, for several reasons. @windows_server_2003 - this is what keeps me from taking it. Some of it may be fixable, and I'm still considering, that's why I left it open.

• First and foremost, the question who this is useful for, for several reasons. In fact, this will not work with 99.999% of ZIP files found out in the wild (I'm not even exaggerating). The unzip command will also not work with the new vram0.img feature, cause ZIPs rely on their *footer*, which we can't provide access to here. You're correct in saying that far more people have 7z installed than OSFmount (for FAT images) or CTRtool (for RomFS), but then - who will have a use for filesystem containers? It's powerusers rather than regular ones, and that type of user can use CTRtool and do the same with an already supported format. The already opened feature requests where about *compressed* ZIP support, btw.
• The implementation is also an issue. I see you did pay attention regarding the write permissions system, but with stuff like that you do add more messup potential (at least on the side of devs). What should actually have been done is to provide mount support for ZIP files, than go through the regular way (mount, copy), so the already existing, tested functions can handle the write permissions. Instead, what we have here is in essence a new, specialized, copy function, handling it's own write permissions. If copying *all* files from a container at once is what you wanted to do, that is something that should better be done in a universal way, in the scripting system.
• Implementation issues continued... stuff in GM9 is meant to work out of the box, especially for users who followed the Quick Setup Guide. Stuff like this, for example, is not really intuitive to handle for the user, and makes the unzip feature feel very incomplete. It's somehow like if I did NitroFS support, but told users, no, NitroFS with folders is not supported, or requires user interaction.
• A smaller issue, but the coding style is not consistent with the remainder of the code (yeah, external libs used also have an inconsistent coding style). That doesn't mean your coding style is bad, it's just not consistent. there are also a lot of global vars used where I think should be much less.

okay I'll close it. I had to make complete one.

 

[Kazuma77]

@Kazuma77 - AGBSAVE9 (and, for that matter, D9, too) has a different problem with dumping saves in that saves are not "wrong", but incompatible with common emulators *and* save patches. This has only been recently fixed in GM9, so GM9 really is the only tool that does it "proper". I use quotes for that because, well, proper is relative here - we're basically working around a messup that happened years ago. Regardless, the GM9 way of doing things is what you want.

As I said, I haven't really messed with GBA injection. I initially had decided not to convert it because it was ripped straight from D9 anyway. But then I thought, well, it does go straight to the option, so, some people might find it convenient. But doing the conversion right is far more important to me. So, thanks for letting me know. I'll definitely be removing it with that being the case.

You're probably not going to like this suggestion, and I understand not wanting to maintain two programs, but, this seems too important not to backport to D9, since people probably aren't going to stop using it. I've been using twin panel file managers for years. But the Windows desktop has all but been the death of proper file management. So, many people probably just find D9 more natural.

Usefulness aside, I was hoping an fc/b would be revealing. That said, Puma and Cakes are smaller. I'll have an easier time finding the right hex pattern with them anyway. Maybe I can do a "left-handed re-compile" of GW.