Might require the bootthis.pub file, too? Or it might require the chinese font file, or chinese language enabled - and somehow refuse to do sound output otherwise? Do you have the chinese firmware, too? As far as I know nobody in dsi-scene has ever seen that firmware.

yep, I have the bootthis.pub file. and the game works fine while I install to hiyaCFW as a title dsiware. so I don't think it's a chines firmware issue

After spending some weeks on NES stuff last month, I had fresh energy for working on unlaunch.dsi. First step was improving the filesystem (with automatically parsed "device:\path\name" strings), and opened doors to adding a filemenu and many more features.

For the filemenu, I was sceptical if it could work fast enough when crawling the whole directory tree. My first attempt took about one second, but then I figured that I could abort directory reading on the first unused entry (as opposed to used or deleted entries), and that made things about 32x faster (ie. one 200h-byte sector vs one 4000h-byte cluster), and the filemenu is now showing up almost instantly (unless you have thousands of files on SD card, of course).

Next version(s) are planned to support lowercase letters & maybe french accent marks and such, reading & displaying icon/title, and some option to change the sort order of the files in the filemenu. But I think the current version does already look quite neat, and includes several details like scrolling & keyrepeat, automatically sensing ROM and SD card eject/insert, different colors for files in different locations.

After adding the filemenu I had originally planned to switch back to loading bootcode.dsi by default... but then nobody would even see the nice new features - so I changed my mind last minute and kept the filemenu as default boot action - but threw in an options screen where one can configure the boot defaults, including redefining hotkeys A,B,X,Y. The filename "bootcode.dsi" is still used (as default for button Y), but one could change that and select any other filename without needing anything called "bootcode.dsi" anymore. Another final addition is including a copy of "wifiboot.nds" as overlay, so one could now do wifi uploads without having the file on the SD card, or even without any SD card inserted.

With the new features, unlaunch can do pretty much everything that the official launcher can do (except gimmicks like making photos & displaying time/date), and you could theoretically completely delete the official launcher .app file. I guess that's now making unlaunch the "First homebrew DSi firmware" ever : )

PS. titlesThe filemenu does show the ASCII titles from carthdr (because the official numeric filenames like 00000001.app aren't of too much use). One funny finding was that most homebrew titles having the field set to "HOMEBREW" or to contain some obscure opcode (that comes out as ".<garbage>". That's making it a bit difficult to select homebrew titles ; )I'll change that in next update, either by using the name from icon/title structure (if it does exist), or otherwise use the filename (for homebrew files, but of course for the official 000000nn.app files). Until then... maybe some devrs will be motivated to use more meaningful titles in the carthdr.

PPS. filenamesThere are two naming schemes for files (and savedata filenames). The offical scheme is using weired numeric folder+filenames, and uses separate "content" and "data" folders - that's used on eMMC (and I think hiyacfw is using that naming scheme on SD card, too).The alternate naming scheme is using more meaningful filenames, like "My Game (EUR+AUS).dsi" combined with "My Game (EUR+AUS).pub" and/or ".prv" in the same folder - I would recommend using that for SD card.Unlaunch is automatically storing the "device:\path\filename.ext" strings in the Device List, with the names converted to short name 8.3 format (with that short names one can have 3-5 directories nested without exceeding the device list's 64 byte limit) (NB the .pub/.prv files are auto-created yet, so you must provide them yourself).

Code:

public & private savedataIf the file is in a folder named "CONTENT", then savedata is stored in aseparata "DATA" folder (this is as how Nintendo is doing it officially): "nand:/../CONTENT/title.tmd" "nand:/../CONTENT/00000002.app" "nand:/../DATA/public.sav" "nand:/../DATA/private.sav"If the file is anywhere else (not in a CONTENT folder), then savedata should bestored in the same folder & same name, with extension changed to .pub or .prv(this homebrew convention allows to use more descriptive non-numeric filenames,and doesn't require "title.tmd"): "sdmc:/../My Folder Name/Filpnote Studio (EUR.AUS).dsi" "sdmc:/../My Folder Name/Filpnote Studio (EUR.AUS).pub" "sdmc:/../My Folder Name/Filpnote Studio (EUR.AUS).prv"As seen above, names can exceed the 8.3 character shortfilename limit (and canuse 16bit unicode), however, using such long filenames can quickly exceed the64 character limit of the DSi's Device List (or it's 8bit character space), asa workaround, unlaunch is converting the above names to 8.3 character formatbefore storing them in the Device List: "sdmc:/../MYFOLD~1/FLIPN~12.DSI" "sdmc:/../MYFOLD~1/FLIPN~10.PUB" "sdmc:/../MYFOLD~1/FLIPNO~2.PRV"With those short 8-character folder names, one can have up to five foldersnested (or only three folders with extension alike "MYFOLD~1.EXT", or more thanfive folders if folder/filename are shorter than 8 characters).As shown in the above examples, the longname ("Filpnote Studio (EUR.AUS)") issame for all three files, but the ~NN suffix may vary for shortnames.

PPPS. autoloadThe new unlaunch version supports the offical autoload by titleid (via 2000300h), and a new alternate autoload method by path\filename (via 2000800h).Alongsides I've figured out a few more details on the structures at 2000000h and 2000300h, and noticed that retails refuse to autoload anything when not having the title list at 2FFD800h. Which, I knew that it did exist, but didn't have much of a clue what it was good for. So, now I know it: It's mostly for autoload (or for accessing pub/prv savedata from other titles), and the title list content varies depending on the started title (it's only containing titles from the SAME maker, plus some system titles like System Settings which are permitted to be autoloaded by to ALL makers).

2FFD800h - Title ListBefore autoloading a title, one should make sure that the title is actuallyinstalled (and which region code it is having, ie. one should use wildcardsthat ignore the lower 8bit of the Title ID when searching the title).The offical way is to look up the Title List in RAM, this is faster thanmanually crawling the directory tree. However, there are some restrictions: TheTitle List contains only titles from the same Maker (as the currently loadedtitle), plus some special "jumpable" system titles. 2FFD800h 1 Titles: Number of titles in below lists (max 76h) 2FFD801h 0Fh Titles: Zerofilled 2FFD810h 10h Titles: Pub Flags (1bit each) ;same maker plus public.sav 2FFD820h 10h Titles: Prv Flags (1bit each) ;same maker plus private.sav 2FFD830h 10h Titles: Jmp Flags (1bit each) ;jumpable or current-title 2FFD840h 10h Titles: Mkr Flags (1bit each) ;same maker 2FFD850h 3B0h Titles: Title IDs (8 bytes each)Related carthdr entries are: [010h].bit0-15 Maker (must match current title for Mkr Flags). [01Dh].bir0 Jump (must be set for Jmp Flags) [230h].bit0-63 Title ID (must be nonzero for being listed) [238h].bit0-31 Public.sav size (must be nonzero for Pub Flags) [23Ch].bit0-31 Private.sav size (must be nonzero for Prv Flags)The list can contain the hidden Nintendo Zone utility, and DSi ROM cartridges(both provided that Maker does match up with current title).The jumpable titles with [01Dh].bit0 that are always in the list are: 00030015484E42xxh ;System Settings 00030005484E4441h ;DS Download Play 00030005484E4541h ;Pictochat 00030004484E47xxh ;Nintendo DSi Browser (if installed)The list does NOT contain the Launcher itself, nor files from System Datafolder (WifiFirmware, Whitelist, VersionData), nor NDS ROM cartridges, noranything where Jmp+Mkr flags would be both zero.If started via 2000300h, then the New Title (from 2000310h) does also receivethe the Old Title ID (from 2000308h) with Jmp flag being set; ie. permitting toreturn to the Old Title (to know which title was the old title, one shouldprobably look at 2000000h, or at 2000308h if that's still intact in memory?).Also, the Jmp flag is always set for the current title; ie. permitting thetitle to reboot itself.

Last edited by nocash on Tue Nov 06, 2018 2:13 pm, edited 2 times in total.

After spending some weeks on NES stuff last month, I had fresh energy for working on unlaunch.dsi. First step was improving the filesystem (with automatically parsed "device:\path\name" strings), and opened doors to adding a filemenu and many more features.

For the filemenu, I was sceptical if it could work fast enough when crawling the whole directory tree. My first attempt took about one second, but then I figured that I could abort directory reading on the first unused entry (as opposed to used or deleted entries), and that made things about 32x faster (ie. one 200h-byte sector vs one 4000h-byte cluster), and the filemenu is now showing up almost instantly (unless you have thousands of files on SD card, of course).

Next version(s) are planned to support lowercase letters & maybe french accent marks and such, reading & displaying icon/title, and some option to change the sort order of the files in the filemenu. But I think the current version does already look quite neat, and includes several details like scrolling & keyrepeat, automatically sensing ROM and SD card eject/insert, different colors for files in different locations.

After adding the filemenu I had originally planned to switch back to loading bootcode.dsi by default... but then nobody would even see the nice new features - so I changed my mind last minute and kept the filemenu as default boot action - but threw in an options screen where one can configure the boot defaults, including redefining hotkeys A,B,X,Y. The filename "bootcode.dsi" is still used (as default for button Y), but one could change that and select any other filename without needing anything called "bootcode.dsi" anymore. Another final addition is including a copy of "wifiboot.nds" as overlay, so one could now do wifi uploads without having the file on the SD card, or even without any SD card inserted.

With the new features, unlaunch can do pretty much everything that the official launcher can do (except gimmicks like making photos & displaying time/date), and you could theoretically completely delete the official launcher .app file. I guess that's now making unlaunch the "First homebrew DSi firmware" ever : )

Tested this new version, and i have to say it's pretty good, as for software issues, there seems to be no problems, as unlaunch works correctly at every boot, on the other side there is an issue that didn't happen before, if you launch the default launcher and you press teh power button once launched, it freezes (this seems to happen even with other apps launched from the launcher), the weird thing is that this thing before happened when launching hiya, but now instead on hiya this no longer happens, while it happen with the stock launcher. Other stuff regards the file browser, the first thing i noticed, and that annoyed me was that the right pad and the b button are threated as the a button, i'm not sure if this is a bug or you intended it in that way, but it gives you some troubles when scrolling, for example when keeping a direction pressed your finger slips and press the right button, the ap is immediately launched. Another thing is that when you launch something, you're not sure if it's been launched or maybe the app crashed, as it just remains in the same screen until the app has finished loading, maybe adding a "loading" text could make you understand what's happening (idk if that could also be integrated with a loading bar). It would also be nice to have hotkeys on the shoulder buttons too, from my experience i know there are people who like to have tons of hotkeys to launch their stuff imediately (i'm not one of them). Last little thing, you should update your how it works "page" in the app, as it still says it automatically boots bootcode.dsi

Quick update, i tested the sd swapping, it detected the sd being removed, but then whenever i put it back it has undefined behaviour: sometimes it shows a new entry with garbage data "];x;", with this info "pub size: 8016, prv size 4341004a, and as path "SDMC:/00000000.APP" (post edit, i tried running that and it refreshed the list corectly), it also shown another wrong entry once, that time with the name of my the last app in the "default" list, so in that case "UGOMEMO-V2" and with path still "SDMC:/00000000.APP", otherwise most of the time it just freezes. Obviously i don't have any file named 00000000.APP in my sd. Another thing but this is just a minor graphical thing, i made some custom dsiwares for my sdnand, and those files in their header have a pub and prv size of 0, but actually it's shown as ffffffff.

This thing isn't completely related to unlaunch but it still concerns that, since nw wifiboot is like "prepacked" i decided to try it, and i coulnd't notice that it managed to connect to my wifi network even if that is wpa2 encrypted, but i couldn't use dslink to upload stuff to it, so was it really connected to my network or it was like a false positive of it trying to connect?

Glad that you say that - looks as if I didn't screw up something that caused all DSi's in your neighbourhood to get bricked. Or are there any angry kids gathering up at your front door?

Power button in Launcher: I've used that many times, and it doesn't freeze here. Which launcher version did you use? I've v1.4E installed, and also tested loading v1.4.2E from SD card, both working okay with power button.Compared to unlaunch v1.7, the launcher is now started directly (without bootstage 2), and it's cart header is flagged to force enabling SD carts, and - after pressing power button in launcher - unlaunch will handle any incoming autoload info at 2000300h. Maybe the freezing is related to that changes.

Control Buttons: How on earth did you manage to hit DPAD-Right - and Button B - during scrolling? Only good that you didn't also hit the Start button in that process ; )Yeah, the buttons were intended as so. You could use either A or B. And I am also often using DPAD-Right & Left as "Enter" and "Exit" (in that manner, I should have also implemented DPAD-Left for leaving the options screen).Anyways, for future versions: Button B (plus Up/Down) is planned to drag files (for changing their sort order). And, I was considering using Left/Right as Page Up/Down.

Title loading progress bar: Yes, I was thinking about that, too. And/or showing the separate loading stages (ARM9, ARM7, ARM9i, ARM7i), and eventually "Done loading, starting title now" at the end. Though the latter should vanish almost immediately after displaying it because unlaunch is clearing VRAM before starting the title.Are there cases where loading takes more than max 1-5 seconds (or freezes completely), while you keep seeing the unlaunch screen? That would mean that something gets wrong in unlaunch itself, before even starting the loaded title.

How it works: Yup, I should update that concerning bootcode.dsi and hotkeys (and the unlaunch.htm webpage, too).

SD card eject/insert: Works fine for me (using an old 128MB SD Card). Sounds as if other cards might need some power up delay after inserting them, Or retrying reading several times until they do response with valid data. Currently the only "delay" is the eMMC being re-read before reading the newly inserted SD card.Surprising that it goes so far to read garbage filenames from the directories. Theoretically it should complain about errors during card initialization, or at least complain about bad MBR/VBR sectors before trying to read directory sectors. Maybe I should review my error handling... hmmm... or maybe there's some switch bounce effect: It might have had actually read the MBR/VBR successfully, and then lost contact for a moment.

Pub/prv savedata size shown as FFFFFFFFh instead of 0: Okay, that's only cosmetic for now. But it might become pricy if I add a function for auto-creating files of that size - then the two 4GB files would instantly exceed the free memory space on 8GB cards.Are you sure that carthdr[238h] and carthdr[23Ch] are really zero? The unitcode in carthdr[012h] is set to DSi, too? If not, then the DSi's extra entries should become zerofilled, either way, the FFFFFFFFh shouldn't happen.Do you know what cluster size you have on the SD card? I am currently loading the carthdr by reading "the first 400h bytes of the first cluster". So that would go wrong badly if the card uses clusters smaller than 400h bytes. I don't know if any cards are formatted like that, common cluster size seems to be around 4000h bytes.

Wifiboot: That's working only with open networks or WEP encryption. WPA2 won't work. Or it might go half way through the connection steps, picking up the router's SSID name and MAC address and channel number - and then hang without going through DHCP and receiving IP addresses.Does wifiboot display SSID and Channel for your WPA2 network? If yes, I should do something to prevent that, ie. if you have two networks, one WEP, and one WPA2, then wifiboot shouldn't hang upon trying to use the WPA2 one.Adding WPA2 support for the DSi's new wifi hardware would be another huge project. I had hoped that somebody would log the traffic on the SDIO bus using some dedicated logging hardware - but I guess that won't happen anytime soon, maybe because off-the-shelf SD/SDIO logging hardware seems to cost around $2000. My new plan would be patching the DSi Browser, so that it'll log all SDIO commands & replies by software.

It appears loading Launcher from SD (as DSiWare I guess) still doesn't work even though the change log seems to suggest you made a patch case for loading Launcher off SD?

Also I would like to test how far this gets on a 3DS, but I think the wifi error screen is still getting in the way. Unlike on DSi, TWL_FIRM on 3DS will have stuff already inited and so you could skip a lot of things.

Unlaunch could still be useful on 3DS. TWLN partition on 3DS is smaller then DSi so not as much DSiWare can be installed to nand (and while possible to resize it, it's not easy for users to do without bricking things as this requires editing the NCSD header of the nand). Plus the 39 or so title limit for DSiWare exists on 3DS too. Currently I use DSi's Stage2 packed to a SRL installed to TWLN and booted by TWL_FIRM to test Unlaunch. I simply replicate the exploit on my SD card since this version of Stage2 I've modified to redirect all reads to SD. (this is another thing you'd have to do to get Launcher to boot off SD correctly but you already know this I believe)

An interesting note about 3DS and DSi's Stage2. Stage2 wants to load the "A" region of Launcher (or the dev version I can't recall at the moment) as it doesn't want to load Launcher from any other location. Not even sure I can provide matching DSi firmware for that region. Probably why I can't DSi System Menu to boot up on 3DS. The closest I got was getting an old pre 0.9 version of Unlaunch to "attempt" booting the "A" version of Launcher by replicating the exploit chain (without the malformed TMD, it gives me a stage2 error screen. Haven't figured out why).

Stage2 should be resetting things back to what a DSi has on bootup so the only reason Launcher is failing is a self check it's own TID compared to the region it's detecting for the console or checks on certain files on SD/NAND. (redirected Launcher's reads to SD to make things easier). At least I was able to get around Stage2 not wanting to boot Launcher by having Unlaunch do it instead. Just can't do that anymore with newer builds of Unlaunch due to wifi error screen.

I provided all the missing files from a DSi on my 3DS to ensure it wasn't working for that reason. But Launcher just white screens. Though there's no real reason to bother doing this if Unlaunch could be made to work on 3DS anyways now that you have a file browser and stuff. I was messing around trying this because I was bored.

I did manage to get DSi System Settings to complete a system update, but Launcher still doesn't boot.

A whole separate build of Unlaunch is probably needed if you want to expand to 3DS TWL_FIRM support. The exploit related code wouldn't be needed. You can just install Unlaunch as DSiWare on 3DS with all the header settings you want as if the DSi was already hacked. (since 3DS has flows in CTR side that allow booting unsigned things and this carries over to TWL_FIRM too as a result)

You are limited by how the hardware is inited on bootup though in that TWL_FIRM will always have things inited a certain way based on the header settings you used in the theoretical Unlaunch SRL you would build for this.

Although you can always just re-init the hardware to get around this if you need to. Aside from that, 3DS in TWL legacy mode is pretty much the same as DSi minus certain things like files DSi Shop would need and things like tickets not being stored on TWLN partition. (3DS has them stored in CTR partition and are not accessible by DSiWare, but this only matters for things like DSi System Settings and Launcher which will probably never boot correctly on a 3DS anyways. Well DSi System Settings will work, but it's not really recommended to use that on a 3DS anyways)

Not sure you own a 3DS though so I guess it's understandable you can't add support for that console unless you get enough donations to afford one.

I suspected that wpa2 support was too good to be true... anyways, on that app I get all(?) the info from the router, bssid, apmac and ssid. Also other than that it shows the channel too. Then it successfully runs "dhcp discover" and then it shows connection failed after about 3 screens of "dhcp next", and in the meantime I can see that the device is connected through my router's settings page.Reading Apache's post instead, I can confirm that the unlatched launcher booted fine from my SD card, while hiya's patched one didn't. I'm on 1.4.5

Power button in Launcher: Just noticed that I had Launcher v1.4.5E installed on the console (not v1.4E). Also just tried loading Launcher v1.4.5E from external SD card. But it doesn't freeze for me when pressing power button.- Does the freeze happen with & without SD card inserted? And with & without ROM cart inserted?- Does the freeze happen in no$gba, too? It doesn't emulate power-button, but clicking "return to DSi menu" might act similar.- Did you configure unlaunch options to use, say, Browser as default for "No Button" and as "Load Error" handler - and then uninstall the Browser? I guess that could semi-brick the console (but should still boot with Button A+B backdoor).

Pub/prv savedata size shown as FFFFFFFFh instead of 0: I just figured out that I was zerofilling the extended DSi header area only for ROM carts, not for DSiware files - which is half correct (because DS Download Play does have/require a Title ID at [230h]) - and half incorrect (because NDS don't have Device Lists at all, and thus should treat [238h,23Ch] as zero).If your DSiware file did have [012h].bit1=0=NDS and [238h..23Fh]=FFh-filled, then, I think that I've solved the problem now.

Patched Launcher: That might conflict with my own patches (which are applied if Title ID matches launcher, with region byte ignored). Or, vice-versa, if you are using a different Title ID, then my own patches would be missing.The .app filename passed to Device List contains the filename with device "sdmc:" when loading it from SD card (unlike your trick with using "nand:" and tweaking it to get redirect to SD card.Aside from that incoming .app filename being on sdmc, I am not using any further patches, ie. the private.sav file and stuff in sys folder are loaded from eMMC (unless your patches are changing that).For using .app on sdmc:, I had to patch carthdr[1B4h] in launcher. There might be problems if you were loading US launcher from sdmc: while having EU files on nand:.

3DS: I have a japanese New 3DS, but I've no idea how to run code on it. Japanese gui is nasty, I can't make sense of the 3DS guide webpage, for actual 3DS titles I didn't even figure out what fileformat they are using or if it's documented anywhere, and the console is booting up so slow that it's unpleasant to use. I never got familar with 3DS.Having an european 3DS might help getting started.Or some way to run DSi code on 3DS, something simple, via flipnote or so, without needing going through 3DS guide.And seeing the 3DS bootroms would be valueable for examining the console from scratch-up, as far as I know they can be dumped - but one could dump them only when already knowing how to run code on 3DS - which I am miles away from.

As far as I understand that's some sort of driver for using different flashcarts with homebrew NDS titles, and it's extremely popular in most of the homebrew scene, and there's no technical documentation about how it's working. There's some open source code available, including a "template" for the driver structure, but it's all very abstract, not really providing info on which bytes are to be stored at which address for which purpose. Or does anybody know how to make sense of it?

For DSi (and unlaunch), it might be useful to supply a DLDI driver that allows old NDS homebrews to read from the DSi's SD/MMC slot instead from flashcart. Is there already such a DLDI driver?The two possible problems would be: A few titles might want to access both flashcart (via DLDI) and SD/MMC slot (via 40048xxh), and might get confused if DLDI redirects to 40048xxh, too. And, NDS can access flashcarts via both ARM9 or ARM7, whilst DSi can access SD/MMC via ARM7 only (or would need a way to forward data from ARM7 to ARM9).

Well as for what changes I've made to Launcher I'm trying to use on SD. I modified the "default" device list table Launcher uses. Found at offset 0x191304 on 1.4E (should be the same for the big 3 regions. Only different with dev versions and perhaps more exotic versions like China/Korea).

This was to ensure that Launcher loads top screen photo from photo partition which I was able to redirect to a photo.img file stored on SD. This seemed to avoid any possible corruption issues/mix ups when switching back and forth from SD Launcher and Launcher on nand. This method also ensured that Flipnote/other DSiWare that reads stuff from photo partition also operated correctly. Tested this mostly with DSi Camera App too. Though I think HiyaCFW is using a different method of redirectiong photo. I think they are redirecting it to a folder on SD. As for other patches, the only other patches I've got on Launcher are mostly the same patches Unlaunch does too like skipping DS Cart White list checks, RSA patches, etc. I seem to recall testing this prepatched version of Launcher on NAND in No$GBA. (the version that redirects to SD) and that did work. Unlaunch boots it correctly and I can have Unlaunch CFW on SD instead of NAND.

Should work on hardware too due to how the Stage2 exploit you are using works. But I never bothered to test that as I wanted my version of Launcher to have working boot splash/menu music.

This was when replacing Launcher on NAND, not using your DSiWare booting functions.

What I am currently trying to do is using your DSiWare booting stuff to launch Launcher instead. (trying to use Launcher as bootcode.dsi for example. This is where I'm having problems getting Launcher to work.)

Anyways this also makes it so any app Launcher boots is booted off SD (and as a result it looks for tmd and app files from SD instead of nand). ALL content Launcher would normally read off nand is read off SD with how I'm starting it with modified Stage2 and the modified device table stored in Launcher. That includes things like wifi settings and the like too!

Of coarse your new Unlaunch versions sorta does this already when you launch DSiWare via button combination or via the new file browser you added.

You already redirect DSiWare to read off SD when using the file browser (or the old button combos from older versions).

What I did was to make sure official Launcher did the same. So when I try to launch this version of Launcher with Unlaunch directly it doesn't work for some reason because I assumed you were doing the same to Launcher too. I did try a vanilla unmodified copy of Launcher as well and that didn't work. At least in previous versions of Unlaunch. Have not had a chance to test that part yet. I could change the TID so Unlaunch treats it like a normal DSiWare app, but I'm pretty sure I can't do that. Launcher has some things it does based on it's own TID that fail. I recall changing TID on Launcher while testing things and it would just error out if I did that.

If your intent to allow booting different versions of Launcher off SD but have it still read nand....that could be dangerous. If the user accidentally gives it the wrong region of Launcher or a version of launcher that decides to remove files from nand that it didn't like this could brick Launcher on nand. Though as I recall that you did make sure that that one particular version of Launcher that would check it's own TMD file wouldn't do that, so I don't see consoles getting full bricked from Launcher version/region mixups. The worst that can happen with my SD redirected Launcher is it deleting things off SD or corrupting something on SD. As far as I can tell Launcher is not able to touch nand anymore with the changes I've made so it should be completely safe.

It's basically like "emunand" on 3DS. CFW on 3DS has emunand patches that redirects all nand read/writes to a hidden section on SD card. Though unlike 3DS, on DSi I'm able to avoid using hidden partitions and the like. It's almost like Nintendo planned to support installing DSiWare to SD at some point but changed their minds....

Anyways the new file browser and options menu is a good addition. I hope you also add ability to toggle which patches to use on Launcher at some point to. I'd like the DSi Boot splash/menu music to be one patch that could be configured to be on or off. With your preference to being off by default. Just give us the option of choosing that.

I'm hoping you get Launcher SD redirection working to a degree you deem satisfactory enough to be a feature in Unlaunch. I have been doing it the way I mentioned above for awhile now and well as others via HiyaCFW and have not really seen any file system related corruption or problems crop up. So having an option for Unlaunch could launch firmware from SD instead of nand would be nice. It allows installing DSiWare or other changes without having to mess with nand and having to deal with the nand crypto.

It also greatly simplifies testing homebrew that I want to install to System Menu. I haven't had to do anything with NAND other then upgrade Unlaunch in quite some time and I'm happy with that.

Would be cool to see Unlaunch get support for this too.

As for 3DS support. Yeah a Japanese 3DS would be hard to work with. Unfortunate you don't have a more suitable one you can use. Currently the best way to hack a 3DS is to use a flashcart like Acekard 2i to exploit a bootrom flaw to install custom FIRM partitions and the like and then install a CFW like Luma. You'd have to also get a "CIA" installer homebrew so you can install CIA's of stuff like DSiWare.

Yeah the 3DS stuff is complicated compared to the DSi stuff you are familiar with. You could perhaps see if someone could donate an already hacked console to you. Then you'd only have to learn how to make CIAs out of your Unlaunch SRL and then you can test things there.

Unlaunch 1.8 seems to be very stable and a huge upgrade! However, if you have a .NDS file that does not have any title information, it will display as a "fuzzy" square. When you are selecting a hotkey, you are able to choose "options" from the list of choices. Not sure if that was supposed to be there, but I just thought that you would want to know. Also, is it possible if you can implement a feature that will load custom images for the background? If so that would be amazing. Is it also possible if you are able to use the Dpad-left and right? They could be used to run more programs, but if you have something else planned for them, that would be fine.

Thanks. Yes, some workaround for homebrew title strings is planned.Allowing to use Options as hotkey... allows you to have a hotkey for changing other hotkeys.Or, in future versions it might get changed to bring up more extended options, similar to System Settings.

Who is online

Users browsing this forum: No registered users and 6 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum