Just released unlaunch.dsi v1.0. The unlaunch exploit bypasses the DSi's official launcher (boot menu & healthsafety screen), and does instead allow to boot your own software from SD card slot, almost instantly after power up. That, with full access rights to all hardware registers.
http://problemkaputt.de/unlaunch.htmAlongsides, I've also uploaded two more updates: no$gba v2.9a (gba/nds/dsi emulator/debugger) and wifiboot v2.2 (for wifi uploading software from pc to dsi). Links are found on the above webpage - using that three projects together is giving a nice development environment (eg. use unlaunch to boot wifiboot, and then wifi upload your homebrew dsi software from no$gba to dsi).
Code:
unlaunch.dsi v1.0 - 24 Jul 2018
- co-releases: no$gba v2.9a and wifiboot v2.2
- webpage: new unlaunch.htm page, with more installation info, new forum, etc.
- speedup: uses DMA for SD/MMC-read, SDIO-write, and AES-read/write, ROM read
- rearranged EXMEMCNT init, ensures ARM9 IPC IRQ enabled before waiting for it
- installer: uses fill_copy_list (instead of relying on carthdr copy in ram)
- installer: stores no$gba footer at eMMC offset FF800h (if it's zerofilled)
- installer: omits FAT writing if FAT unchanged (as so on unlaunch updating)
- installer: disables BPTWL powerbutton auto-reset during install_now
- sdmmc/sdio: removed pre-wait and soft-timeouts, instead checks hw error bits
- initializes SOUNDBIAS (maybe better in case games don't do that themselves)
- moved GIFs to separate non-lz77 memory block (avoid double compression)
- verifies camera chip id and emmc cid/csd with warning if unknown hardware
- added Y button hotkey: load NDS/DSi title from ROM-cartridge slot
- rom loader: cartpower, romctrl, 4004012h/14h, load chip id and secure areas
- rom speedup: uses 1000h-byte blocksize for faster 1t-rom loading
- rom speedup: forces fast mrom timings for mrom carts with wrong cart header
- rom speedup: forces less slow 1t-rom timings for actual 1t-rom carts
- rom speedup: forces reduced secure area delay of 8ms for 1t-rom carts
- rom speedup: uses slot-swap-reset-trick (instead slow power-off/on)
- rom speedup: crops hardcoded cart power-on delays to 1ms/1ms/0ms/1ms
- more accurate modcrypt (old was overcomplicated, and bugged on size=0)
- supports place_aes_keys (maybe needed for jpg/camera or verdata stuff)
- sets POSTFLG register (needed for NDS titles like EragonDemo, DownloadPlay)
- moved twlcfg/wlfirm/hwinfo elsewhere (reloc to 2000400h only for DSi titles)
- resumes default BPTWL powerbutton mode (unless when booting nds-titles)
- enter_nds_mode: reloc 2FFFxxxh to 23FFxxxh, set 4MB-RAM, NDS-ROM, ARM9 67MHz
- enter_nds_mode: set NDS-TSC-touchscr mode, init NDS-Wifi, NDS-SNDEXCNT
Code:
wifiboot v2.2 - 24 Jul 2018
- renamed asm source/binaries from dslink+dswifi to wifiboot+wificore
- rearranged EXMEMCNT init, ensures ARM9 IPC IRQ enabled before waiting for it
- adjusts BPTWL powerbutton mode for wifiboot itself and booted nds/dsi titles
- enter_nds_mode: reloc 2FFFxxxh to 23FFxxxh, set 4MB-RAM, NDS-ROM, ARM9 67MHz
- enter_nds_mode: set NDS-TSC-touchscr mode, NDS-SNDEXCNT
Code:
no$gba v2.9a - 24 Jul 2018
- emu/dsi/clk: supports ARM9 134MHz mode (but waitstates are too fast for now)
- bios/help: swi waitbyloop timings for arm7/arm9 rom/cache nds/dsi 67mhz/134mhz
- cart/emu: supports ds cart reset tricks (via toggling scfg_mc_msb or exmemcnt)
- dsi/emu/help: scfg_clk.bit7 is read-only on arm9 (value mirrored from arm7)
- dsi/help: added notes on 'flipnote lenny (or whatever it is called)' exploit
- dsi/help: solved unknown last bytes in boot info block (SHA1 on 60h-byte area)
- dsi/mmc-image: alternately accepts no$gba-footer at emmc offset FF800h
- nds/dsi/cart/help: romctrl notes on (in-)official ways to reset cartridges
- nds/dsi/cart/help: romctrl notes on wrong and slow 1t-rom timings cart header
- dsi/debug: reformatted scfg7/scfg9 iomap windows, with new scfg details
- dsi/teak/help: added offical names for bits in ar/arp/stt/mod (from .dll)
- dsi/teak/help: many new stt/mod/ar/arp/cfgi/a0e/vtr details (thanks wwylele)
PS. I've originally released earlier unlaunch versions in this forum,
http://4dsdev.kuribo64.net/thread.php?id=171 then switched to this forum,
http://forum.gbadev.org/viewtopic.php?t=18147 (and then switched back). Well, and after unexpected troubles in both forums, the project finally ended up in nesdev other retro dev section : )
I attempted to install Unlaunch via bootcode.dsi (haven't tried if it works via hbmenu/other exploits yet. I do recall 0.9 installer would black screen if booted with anything other then Unlaunch bootcode.dsi) and I get this screen. Photo attached as attachment. Using a DSi XL (USA region) so nothing special.
Does this screen only occur on the installer phase? Safe to install manually?
EDIT: Booting unlaunch.dsi via hbmenu with exploit games like Sudoku works again on 1.0. But still get the unknown EMMC message.
Wonderful work.
It works on a Japan NDSi Console with 1.4.5J.
Boot speed observably speed up to about 3s.
In constract, it will spend about 10s at v0.9.
edited: Test DSi browser works well.
Of course, you have to configure link info at dsi system settings and turn on wifi because of settings check.
What's more, flashcard like supercard dstwo cannot be booted by pressing button B.
Released unlaunch v1.1 at
http://problemkaputt.de/unlaunch.htm (only difference is removing the warning for unknown CSD in KLM5617EFW type eMMC chips).
Apache Thunder wrote:
I attempted to install Unlaunch via bootcode.dsi (haven't tried if it works via hbmenu/other exploits yet. I do recall 0.9 installer would black screen if booted with anything other then Unlaunch bootcode.dsi) and I get this screen. Photo attached as attachment.
EDIT: Booting unlaunch.dsi via hbmenu with exploit games like Sudoku works again on 1.0. But still get the unknown EMMC message.
Thanks, looks like a KLM5617EFW chip, the CID for that chip was already known, but the CSD is a good bit different compared to older KMAPF0000M chips:
Code:
Known CSD's for DSi eMMC chips (excluding CRC in LSB, padded 00 in MSB)
8 16 24 32 40 48 56 64 72 80 88 96 104112120pad ;<--bit numbers
40 40 96 E9 7F DB F6 DF 01 59 0F 2A 01 26 90 00 ;DSi CSD KMAPF0000M-S998
40 40 8E FF 03 DB F6 DF 01 59 0F 32 01 27 90 00 ;DSi CSD KLM5617EFW-B301
? 00 ;DSi CSD blurb?
? 00 ;3DS CSD
And the differences are...
bit name KMAPF0000M KLM5617EFW
112-119 TAAC 26h=1.5ms 27h=15ms
96-103 TRAN_SPEED 2Ah=20MHz 32h=25MHz
42-46 ERASE_GRP_SIZE 1Fh=32x32 00h=1x32
32-36 WP_GRP_SIZE 09h=10 1Fh=32
26-28 R2W_FACTOR 05h=32x 03h=8x
Not sure if that values are really correct, or if the manufacturer has screwed up some bits. TAAC being 10x slower in newer chips looks weird, 20MHz would be for 1bit MCC (whilst 4bit MMCplus/MMCmobile should support 26MHz), erase group 32x32x512 bytes would somewhat require 512Kbyte clusters, write protect group size 10 decimal looks a bit odd (though it could be true), and well, faster writing in newer chips looks plausible.
Didn't knew that v0.9 didn't boot up from within hbmenu, but if it's working with v1.0 up then it's all fine.
Btw. when booting unlaunch.dsi directly (renamed as boot.nds) from within 4swordhax... does that still have problems?
SLKun wrote:
Boot speed observably speed up to about 3s.
In constract, it will spend about 10s at v0.9.
edited: Test DSi browser works well.
Of course, you have to configure link info at dsi system settings and turn on wifi because of settings check.
What's more, flashcard like supercard dstwo cannot be booted by pressing button B.
Oops, 10 seconds boot time shouldn't have happened. And 3 seconds shouldn't happen either (normally it should be around 0.5s).
The 10 seconds might have been because the old version didn't use DMA and such stuff (so loading a very large bootcode.dsi file from SD card may have been pretty slow).
And the remaining 3 seconds, that might include extra overload that occurs after loading+starting your bootcode.dsi file (ie. if it's loading further data after it got started).
I am normally using wifiboot.nds renamed to bootcode.dsi, and the "WIFIBOOT" message pops up "almost instantly". The biggest bottleneck is uploading the wifi firmware (done upon coldboot by unlaunch, not by wifiboot), that takes around 400ms on older W015 wifi boards (with W024 boards it's much faster, and upon warmboot it takes only around 50ms to init the wifi hardware on either W015 and W024). The other bottleneck might be large files (bootcode could be up to 6.25MByte for DSi titles, and hardware transfer speed is about 8Mbyte/s for SD/MMC, so that could eat up almost one second... or longer if I've still screwed up something). And well, the final slowdown is that, I think, most people are currently using unlaunch to reload the patched/original firmware so loading speed would be about as slow as without unlaunch.
DSi browser is working when booting it directly (eg. when loading it as bootcode.dsi and bootcode.prv files)? Then my code for wifi firmware uploading seems to be actually working (for initializing the new atheros hardware for commercial DSi titles).
I haven't tested with flashcarts yet. I have a "acekard2i" somewhere. And I could test other flashcarts (of somebody donates one for testing). At the moment I could only guess that the problem might be related to uncommon chip id, or romctrl values, or missing support for 1000h-byte blocks, or requirements for additional delays.
Speaking of ROM cartridges, the NDS-era carts are booting quite fast (less than 1s, about 0.3s or so), but I've been pretty shocked and scared when trying to boot DSi-era carts (using the official loading procedure it took up to 4s for cooking coach). Reasons are that newer carts are using cheaper/slower 1T-ROM chips (instead older/faster MROM), with unneccessary slow timings/delays declared in cart header (even for some MROM carts, that are accidently assigned to use slow 1T-ROM timings), lack of support for 1000h-byte block loading in firmware, doing switching cart-power off/on between loading nds and dsi areas, and simply more bloated code in newer cartridges.
I've tweaked a bunch of things to get that newer carts booted at reasonable speed, it should be at least twice as fast as with original firmware. But maybe one of that tweaks is causing issues with flashcarts (though most of the tweaks should be probably working there, too, so I wouldn't want to remove
all tweaks just for the reason that some of them might cause issues).
Oh, and there are also some ROM carts that I don't know if they are working. Especially those with "NAND" memory, or with "IR" ports.
I tried to update from unlaunch 0.8 to the latest release and even if it installs fine, when i boot the console it just freezes on the unlaunch logo if booted with no bootcode/by pressing a, while if i try to run hiya via bootcode it freezes on a black screen, i tried the version between the 0.8 nd the 1.1 and those too have the same freeze issue. The only things i can run are the homebrew that doesn't access the system menu, like hb browser. I'm on a dsi xl with firmware 1.4.5 e
Yeah booting directly as boot.nds from 4swordhax still doesn't work. I believe I tried that when trying to get around the unknown emmc error.
Also 1.1 works now for my DSI XL. Tested the new cart loader. Blackscreens when trying to boot my Cyclo iEvolution flashcart if the cart is in TWL mode. Is able to boot my R4 but not my DS-Xtreme. (same issue, blackscreens).
I tested Mario Kart DS booted from R4 from your new cart loader. Game hangs the moment I go the multiplayer menu. Seems like Wifi is incorrect state?
It also fails the same way from my Acekard 2i so likely not an issue with the cart I used. Booted Mario 64 DS directly as well. It also hangs when trying to use the multiplayer menu.
My Sonic Classic Collection cart is also bootable. It's a TWL cart too but can't tell if it's in TWL mode or not. It's hard to tell with that cart though but I guess it is? I don't really have any other TWL carts so wouldn't know. I assume you do detect if it's a TWL cart and boot it in TWL mode with the extended binaries loaded and everything.
I think the DS-Xtreme might be failing to boot due to secure area check fail. I recall having to disable that check in NTR Launcher to get that cart to boot. But not sure if you're code is doing the same. There's no error handling with your cart handler. At least nothing it will display. Just blackscreens on the carts it failed to boot. DS-Xtreme is a bit wierd though. It's header loads arm9 binary from odd location in rom. At 0x100000 or so instead of the normal 0x4000. Even patched Launcher fails to boot it.
On that subject I hope you at least open source parts of your Unlaunch. Maybe the DSiWare and cart loading part can be open source? NTR Launcher I would love to add TWL cart support to. But the cart loading code it uses is ancient (uses same code from Nitrohax) and I don't understand the code well enough to fix it myself.
Oh one more thing. I noticed I was able to boot my Acekard 2i despite having ntrboothax installed to it. So it seems your card init code can trigger Acekard to use the first rom region instead of the retail rom region. So that's cool. ntrboothax users can still use Acekard 2i as a normal flashcart with Unlaunch if booted directly. NTR Launcher still causes it to try using retail rom region.
edo9300 wrote:
I tried to update from unlaunch 0.8 to the latest release and even if it installs fine, when i boot the console it just freezes on the unlaunch logo if booted with no bootcode/by pressing a, while if i try to run hiya via bootcode it freezes on a black screen, i tried the version between the 0.8 nd the 1.1 and those too have the same freeze issue. The only things i can run are the homebrew that doesn't access the system menu, like hb browser. I'm on a dsi xl with firmware 1.4.5 e
But it did work with unlaunch v0.8? And if you take a copy of eMMC, does the eMMC image work in no$gba, or does it freeze there, too?
If not: Are you sure that you have the launcher installed? You need both .tmd and .app files for launcher (just mentioning because unlaunch v0.6 didn't write-protect both files, so data managment may have deleted the .app file) (also .app and .tmd must be for the same firmware version, and matching your console region; just in case you tried to replace the file(s) by a different version?).
I can confirm that my device, which also failed to run Unlaunch0.9, has an issue 1.1. It is running 1.4.5A, which is a firmware on which many have had issues with 0.9. However, unlike with 0.9, I can boot into HiyaCFW. I just can't get to the regular DSi System Menu. On 0.9, neither was possible, though we could still run other bootcode.dsi files such as the installer for 0.8.
No such issue on my device running 1.4.2A, complete functionality as far as I can tell.
I'll be testing both of these eMMCs with no$gba soon and will report back.
nocash wrote:
edo9300 wrote:
I tried to update from unlaunch 0.8 to the latest release and even if it installs fine, when i boot the console it just freezes on the unlaunch logo if booted with no bootcode/by pressing a, while if i try to run hiya via bootcode it freezes on a black screen, i tried the version between the 0.8 nd the 1.1 and those too have the same freeze issue. The only things i can run are the homebrew that doesn't access the system menu, like hb browser. I'm on a dsi xl with firmware 1.4.5 e
But it did work with unlaunch v0.8? And if you take a copy of eMMC, does the eMMC image work in no$gba, or does it freeze there, too?
If not: Are you sure that you have the launcher installed? You need both .tmd and .app files for launcher (just mentioning because unlaunch v0.6 didn't write-protect both files, so data managment may have deleted the .app file) (also .app and .tmd must be for the same firmware version, and matching your console region; just in case you tried to replace the file(s) by a different version?).
i tried running 2 backups, one with unlaunch 0.8 and the other with unlaunch 1.1, the result is the same as on the ds, the one with 0.8 boots fine, the one with 1.1 doesn't
I'm getting a wierd bug installing the newer versions of unlaunch. I have unlauch 0.8 on my dsi. I tried to install 0.9 when it was compatible with ndsbootmenu and every time i tried it installed correctly but when i go to reboot my system it said it was using 0.8 not 0.9. I tried doing the install several times but it did not work, robz8 said it may be a "phantom install" but im not 100% sure. So now i have tried installing the newest version 1.1 and im still getting the "phantom install" issue, everything says it installed correctly but its still showing that im using 0.8.
Hmmmm, okay, I see, the new patch added in v0.9 doesn't work for firmware v1.4.5. Added one more wildcard, so it'll find/patch the correct opcodes in next version. And I should be really more careful when adding new patches (but there are none planned at the moment anyways).
robzombie91 wrote:
I'm getting a wierd bug installing the newer versions of unlaunch. I have unlauch 0.8 on my dsi. I tried to install 0.9 when it was compatible with ndsbootmenu and every time i tried it installed correctly but when i go to reboot my system it said it was using 0.8 not 0.9. I tried doing the install several times but it did not work, robz8 said it may be a "phantom install" but im not 100% sure. So now i have tried installing the newest version 1.1 and im still getting the "phantom install" issue, everything says it installed correctly but its still showing that im using 0.8.
The installer displays V1.1, but after installing & reboot, it's showing V0.8? Weird, sounds as if the eMMC writes are completely ignored, but I wouldn't know how/why that could happen. Or do you have the V0.8 installer on your SD card (renamed as bootcode.dsi)? Then it would reboot that file, asking you if you want to install V0.8.
Apache Thunder wrote:
I tested Mario Kart DS booted from R4 from your new cart loader. Game hangs the moment I go the multiplayer menu. Seems like Wifi is incorrect state? ... Booted Mario 64 DS directly as well. It also hangs when trying to use the multiplayer menu.
I think the DS-Xtreme might be failing to boot due to secure area check fail. I recall having to disable that check in NTR Launcher to get that cart to boot. But not sure if you're code is doing the same. There's no error handling with your cart handler. At least nothing it will display. Just blackscreens on the carts it failed to boot. DS-Xtreme is a bit wierd though. It's header loads arm9 binary from odd location in rom. At 0x100000 or so instead of the normal 0x4000.
Don't know why the Mario games hang on multiplayer. I've tried Metroid demo cart multiplayer, that looks right (it doesn't hang, but I've no second cart for actually testing multiple players in there).
Didn't knew that there are carts with ARM9 code elsewhere than 4000h. If it's at 8000h or higher then the special 16Kbyte area is left unused, and the encryption for first 2Kbyte is also omitted (at least it's so on NDS, a DSi would probably refuse such carts completely).
I think that I've already implemented that case properly... except that I am still issuing dummy read commands for the special 16Kbyte area... maybe the flashcart doesn't support that commands at all and gets confused when receiving them - I can try to omit them on carts with ARM9 at 8000h or higher in next version.
when i did the install i did it with the 1.1 unlaunch.dsi. i removed the 0.8 installer. But yeah it still displays 0.8 when booting
@nocash
I will try to not derail this thread too much and ask a related question. What I would like to know if the wifiboot exist for something like the ds lite? I have a few of them amassing dust at home since the kids don't use them (and mostly destroyed them.. kids, you know
) and the flash card I had mostly died in the first years I received it as a gift so I don't have much way to write anything for them anymore.
I didn't search on the subject yet since I'm not working on any related project but this thread got me interested to know more about it.
There is WiFiMe, usable with a FlashMe'd DS (to skip DS Download Play's RSA check). But I think that requires a USB WLAN adapter with a certain Ralink chipset.
Ok noticing a minor graphics issue when booting a cart via the cart loader. Best I just show it. I noticed this when my R4 boots up via the cart though that cart clears it out by the time WoodR4 is done booting. But this cart doesn't really recover. Yeah the Max Media Dock cart doesn't do much of anything on a DSI, but it was another cart I had so thought I'd test it with Unlaunch.
Don't think I've seen this occur with retail games, but it's abnormal since I don't see this when booting them normally so it might present unexpected issues with some carts perhaps?
I'll note here that 1.1 seems to have been successfully installed and is functioning correctly on my 1.4.5A DSi.
Banshaku wrote:
What I would like to know if the wifiboot exist for something like the ds lite?
Yes, wifiboot (and dslink) are normal NDS tools, you could boot them on any NDS console from flashcart.
Or, without flashcart: You could install the DS Xboo firmware: That's leaving about 200kbytes free space on the firmware chip, which can be used to install a small NDS rom-image in firmware memory (eg. wifiboot). The thing that had kept most people (if not everybody) from doing that is that the installation stuff relies on having a bunch of wires connected to parallel port (and with some more wires you could also upload software via cable, at speeds faster than wifi's 2Mbit/s).
tepples wrote:
There is WiFiMe, usable with a FlashMe'd DS (to skip DS Download Play's RSA check). But I think that requires a USB WLAN adapter with a certain Ralink chipset.
Could be nice... if there are more than a few people having compatible WLAN adaptors. And I guess one would additionally need a flashcart or other hardware for patching the firmware's RSA check (unless there's a way around that, I guess could find exploits in rsa-signed games, or use the rsa-signed menu from demo stations).
Anyways, the thing that I am interested in would be transfer protocol. Is there any source code for WiFiMe? Or are there homebrew single-cart multiplayer NDS games? It would be nice to know how to make such games (though they would work only when patching the RSA check at receiver side), and it would be nice to implement the receiver side in DS Xboo firmware someday.
Apache Thunder wrote:
Ok noticing a minor graphics issue when booting a cart via the cart loader.
Might be because I haven't cleared all vram and palette memory. I could have a look at supporting those flashcarts - if you could upload rom-images for the flashcart bootmenues somewhere.
I should probably also clear main ram and wram (though commercial games seem to do that themselves). But I don't like the idea of zerofilling 16Mbytes of memory. I guess something SwiCpuSet could be relative fast, and DMA might be a bit faster, probably clearing 4 bytes per clock cycle at 33MHz, so 16Mbytes would take 125ms, plus some more time for wram & vram : /
I do have a rom of the DS-X (at least 1.2 firmware version of the cart. You probably wouldn't need all of them)
I can rom dump the Cyclo iEvolution but I bet it may be an issue with the game it's pretending to be while in TWL mode. Look to see if you have issues booting the Cooking Coach game it is pretending to be. If the real game works...not sure why the iEvo one wouldn't I could rom dump it but that wouldn't help It would just be the same one the real game uses. (it's exploit code is in the save file. I can probably dump that if you want it)
I have the decrypted boot menu for iEVo too. I was able to boot the cart with that and skip loading the game. But it fails to boot any DSi Enhanced roms though. I think there's something the exploit code in the save file of the spoofed Cooking Coach rom may be setting up first maybe?
Anyways the R4 works fine.
I think you just need to clear VRAM/Palette data and it will be fine. Clearing main ram is probably not a good idea.. It would break the soft-reset data region some apps could use to make Launcher auto boot things.
I've attached the rom dump of the DS-X below:
Attachment:
File comment: ZIP file containing rom dump of DS-X.
_SD_TF_NDS_ASMA00.zip [115.64 KiB]
Downloaded 333 times
EDIT:
and the iEvo files if you want to look at those:
Attachment:
iEvo.zip [582.55 KiB]
Downloaded 263 times
I uploaded the original iEvo boot menu SRL. I have one I converted to a SRL System Menu can launch, but that's probably not what you want to look at right now.
So after emailing with nocash about an unkown emmc/cid error with unlaunch, he asked me to take a picture of the chip. i hope i took a picture of the right one, but here it is.
I hope its clear enough.
Many thanks! I'll remove the unknown chip warning in next version. The picture is clear enough, in fact the resolution is a bit overkill, but the chip's part number is pretty well legible:
ST, NAND02G, AH0LZC5, HH563 8Y, KOR 99 935
Going by similar datasheets (for non-eMMC chips), the "02G" stands for 2 gigabit, and the next some letters should be package/temperature/voltage/bustype and the like.
That ST chips appear to be quite rare. There've been only two people reporting the unknown eMMC warning message showing up in unlaunch; showing these values:
Code:
AC XX XX XX XX 30 36 35 ;\CID
32 43 4D 4D 4E 01 FE 00 ;/
00 40 8A E0 BF FF 7F F5 ;\CSD
80 59 0F 32 01 2F 90 00 ;/
80 80 FF 80 00 04 00 00 ;OCR etc ...
00 00 00 00 01 00 01 00
00 00 00 00 00 00 00 00
00 09 00 00 00 01 D0 40
00 00 01 00
The date code in first byte can be AC or BC (the one in the above photo has value AC), with C meaning year 1997+12=2009, and A/B meaning october/november. So it seems that nintendo has used that ST chips only for a short period, close to the launch of the DSi XL console (unless other people have ST chips with other datecodes).
The differences in the CSD value translate to:
Code:
Samsung Samsung ST
bit name KMAPF0000M KLM5617EFW NAND02GAH0LZC5
112-119 TAAC 26h=1.5ms 27h=15ms 2Fh=20ms
96-103 TRAN_SPEED 2Ah=20MHz 32h=25MHz 32h=25MHz
79 READ_BL_PARTIAL 0=No(?) 0=No(?) 1=Yes
62-73 C_SIZE 77Fh=240MB 77Fh=240MB 3D5h=245.5MB
59-61 VDD_R_CURR_MIN 6=60mA 6=60mA 7=100mA
56-58 VDD_R_CURR_MAX 6=80mA 6=80mA 7=200mA
53-55 VDD_W_CURR_MIN 6=60mA 6=60mA 7=100mA
50-52 VDD_W_CURR_MAX 6=80mA 6=80mA 7=200mA
47-49 C_SIZE_MULT 6=256 6=256 7=512
42-46 ERASE_GRP_SIZE 1Fh=32x32 00h=1x32 1Fh=32x32
32-36 WP_GRP_SIZE 09h=10 1Fh=32 00h=1
26-28 R2W_FACTOR 05h=32x 03h=8x 02h=4x
14 COPY 1=Copy 1=Copy 0=Original
Released unlaunch v1.2 -
http://problemkaputt.de/unlaunch.htmCode:
v1.2 05 Aug 2018
- rom loader: variable ARM9 secure area size=4000h..1000h, or skips if none
- zerofills vram/oam/palette before starting other titles (takes about 6ms)
- arm7_copy_scfg_state_to_ram_and_wram (passes SCFG_OP to ARM9 side)
- supports twl-debugger (with 80h-byte address shift, without region patches)
- removed forced SFCG_EXT.bit31=1 patches (since they weren't too useful)
- fixed color-flash on patch errors, resumes further patches after keystroke
- added wildcard for anti-black-fill patch (did hang firm v1.4.5 since v0.9)
- moved unknown camera/emmc warnings after dsi-mode check, ie. not in nds-mode
- removed warning on unknown CID/CSD for ST NAND02GAH0LZC5 eMMC chips
I've benchmarked some memory fill methods. Filling the whole VRAM via STMIA opcodes takes around 6ms, which is more or less acceptable. Filling Main RAM is pretty slow, and timings depend on how it's done:
- 120ms for filling 2Mbyte via STMIA opcodes (if destination is uncached)
- 54ms for filling 2Mbyte via STMIA opcodes (if destination is cached-with-writebuffering)
- 49ms for filling 2Mbyte via DMA transfers
So filling 16Mbytes (for DSi titles) would take about 400ms, and filling 4Mbytes (for NDS titles) would take 100ms. That's even slow than I had thought (parts because I forgot that main ram is using 16bit databus, not 32bit, and because there seems to be some further overload, maybe the hardware inserts extra cycles after each 16-byte snippet or so). Anyways, 400ms is too slow.
The three different eMMC chips are now accepted without warning (but the warning is kept in there, in case some consoles have yet different chips).
The unknown camera warning is also kept in there - but so far nobody has reported it being triggered, so it seems that nintendo has never used the unknown camera devices, and all consoles contain the same aptina cameras. But who knows, maybe some rare/early consoles have the unknown cameras in there.
Btw. speaking of those cameras, their initialization sequence is documented here:
http://problemkaputt.de/gbatek.htm#dsia ... nufacturer does anybody know a camera/datasheet matching that sequence? Register [03h] is apparently some "bank" registers for accessing more than 256 registers, and there are other characteristic things like writing an array with 22 increasing numbers to [1:8Dh+(0..21)]. I guess anybody who has ever worked with that cameras will immediately recognize them.
I could/should also add warnings about Chinese iQue DSi consoles having an "unknown firmware", as well as early japanese ones with firmware v1.0 (assuming that that version did actually exist). Or, if somebody has already dumped such firmwares, please let me know. I would be mainly interesting in getting a filesystem tree with filenames, filesizes, and crc32's, for checking if there were different or completely missing system files on that consoles.
My DS-X still isn't bootable with the cart loader as well as my Cyclo iEvolution when that cart is in DSi mode. (will load the the cart fine if the cart is in NTR mode and is using the NTR rom) I'm guessing you haven't had a chance to look at that for 1.2 yet.
The graphics corruption for R4/Max Media Dock cart is gone so looks like the VRAM/Palette clear fixed it.
Also, tried to run Unlaunch 1.2 installer as bootthis.dsi just blackscreens....Odd. It ran fine as boot.nds from sudokuhax however.
Found a bug when having homebrew named as "bootcode.dsi".
The power button doesn't work, if set to IRQ. It only works when setting it to Auto-Reset.
I don't recall the issue occurring in previous Unlaunch versions.
Tried the 1.2 and still i get stuck on startup on unlaunch's screen, i also tried the cardboot feature, and i couldn't manage to run some games, and i found that the only difference between those games that boots and the ones that don't is that those games use wifi featuers. I think that probably this is still related to the fact that i cannot boot into system menu with versions after 0.8, interesting fact, i tried some old ones, and while the 0.6 works, the 0.7 has the same issue. Also i tested this version on my nand backup used with no$gba, and it works...
Update, i done another backup of my nand, with unlaunch 1.2 installed (that didn't boot), and on no$gba it does
Robz8 wrote:
Found a bug when having homebrew named as "bootcode.dsi".
The power button doesn't work, if set to IRQ. It only works when setting it to Auto-Reset.
I don't recall the issue occurring in previous Unlaunch versions.
The last change to power button was in unlaunch v1.0 (switching it power-button-IRQ-mode) (the older versions had it set to power-button-auto-reset mode).
If IRQ mode doesn't work... maybe it does still have an old IRQ pending and refuses to issue a new IRQ until acknowledging the old one... by reading BPTWL register 10h? Or maybe the IRQ and pin-direction isn't configured in GPIO registers? Or something in IE2/IF2 registers?
Do you have a link to some homebrew title that shows the effect?
Apache Thunder wrote:
My DS-X still isn't bootable with the cart loader as well as my Cyclo iEvolution when that cart is in DSi mode. (will load the the cart fine if the cart is in NTR mode and is using the NTR rom) I'm guessing you haven't had a chance to look at that for 1.2 yet.
Cooking Coach is working on my console (showing the game's loading screen, and then triggering the dslink exploit). The exploit used in iEvolution might be a bit different... or, if you don't even see the cooking coach loading screens: Then it must be some hardware issue with the cartridge imperfectly cloning the dsi-cartridge hardware. Not much that I could do about it without having one of those cartridges.
The "raw" iEvolution menu (without the cooking coach stuff) was interesting because it didn't work with no$gba's low level cart emulation (because it's reading ARM9 code from offset 200h, ie. from within the cart header area - that's actually NOT working on official carts, but custom flashcarts could do so - I've changed the emulation to accepts such reads if the cart header is pointing such offsets).
What is a DS-X, another flashcart? I don't have a ROM-image for testing that.
Apache Thunder wrote:
Also, tried to run Unlaunch 1.2 installer as bootthis.dsi just blackscreens....
Odd, that doesn't happen for me. I am normally using wifiboot to upload the installer. But renaming unlaunch.dsi to bootthis.dsi works fine for me, too.
edo9300 wrote:
Tried the 1.2 and still i get stuck on startup on unlaunch's screen, i also tried the cardboot feature, and i couldn't manage to run some games, and i found that the only difference between those games that boots and the ones that don't is that those games use wifi featuers. I think that probably this is still related to the fact that i cannot boot into system menu with versions after 0.8, interesting fact, i tried some old ones, and while the 0.6 works, the 0.7 has the same issue. Also i tested this version on my nand backup used with no$gba, and it works...
Yeah, my launcher patches did hang when loading firmware v1.4.5 in most unlaunch versions. That issue occured in v0.7 and v0.9-v1.1. But it should work okay in unlaunch v1.2. But you have got it installed, and it's showing the correct versions string for v1.2 (NOCASH UNLAUNCH.DSI V1.2) and just hangs there? Well, then that would be some different issue unrelated to the patches...
You have made a eMMC from the non-working state, and that's working in no$gba? And you have the Reset/Startup Entrypoint option set to "GBA/NDS BIOS", so it's showing the Unlaunch loading screen, and then boots into the official boot menu?
If that's working then it seems to be more a hardware issue... I've tested unlaunch with both wifi board versions and they are both working okay. Different eMMC chips probably shouldn't cause problems (but I've only the KMAPF0000M-S998 one for testing). Uhm, or different Console IDs... that might be a problem if you have used a firmware from a different console (like trying to run a european firmware on a japanese console)?
PS. The wifi issues... which games are affected by that? And are that NDS games or DSi(-enhanced) games? And do you know which DWM-W0xx wifi board version you have in the console?
EDIT: Found a terrible mistake: Skipping wifi init was supposed to be done when pressing button Y, but I've somehow assigned it to button B, ie. the same button as for booting from ROM cartridge slot - so that should explain wifi issues for ROM cartridges.
The iEvo SRL I was able to manually rebuild to a version that System Menu can use. It loads arm9 to an address higher then the normal 0x2000000 so I was able to offset it to account for a blank secure area without issue.
(By simply having load address 0x800 lower then entry address so the entry address is still at the original location)
Anyways the cart doesn't even show the Cooking Coach boot logos. Just blackscreens. I guess not much can be done about it if you have the original game it's spoofing working. The cart is still going for $40+ on the one flashcart site that's still selling it so yeah it's still expensive to get.
As for my DS-X. I did post the rom image for it in a previous reply. You must have missed it. Here's the link to it I had attached to that reply:
download/file.php?id=13190
nocash wrote:
If that's working then it seems to be more a hardware issue... I've tested unlaunch with both wifi board versions and they are both working okay. Different eMMC chips probably shouldn't cause problems (but I've only the KMAPF0000M-S998 one for testing). Uhm, or different Console IDs... that might be a problem if you have used a firmware from a different console (like trying to run a european firmware on a japanese console)?
Yeah, i too was suspecting it was an hardware issue, now i'm asking myself if it's because of damaged components or some different chips of the ds. As for the firmware, i didn't do nothing of those things, i only installed unlaunch via flipnote and that's all, i didn't modify my nand in other ways. I could send pics of my console if needed
I've tried loading unlaunch.dsi as bootthis.dsi a few more times. It doesn't completely hang for me. But there's something murky: Sometimes loading takes about 2-4 seconds longer than it should, and the installer is then randomly complaining about camera ID's being all FFh's, or the console being running in NDS mode, and/or the power-button-auto-reset not being working.
The problem seems to occur mostly when trying to install a different version than already installed (even if there are only a few bytes of code changed, but it works as soon as those same changes are applied to both the installer & already installed version). So it looks as if the loaded data is ignored, or as if cache isn't updated - ending up with newly loaded code mixed with old code in memory.
I haven't yet figured out what is wrong there. But unlaunch v1.2 seems to be quite unstable.
I've added a "don't use!" warning for that version on the webpage.
Apache Thunder wrote:
As for my DS-X. I did post the rom image for it in a previous reply. You must have missed it.
Ah, the "_SD_TF_NDS_ASMA00.zip" file. Yup, I tried that... in no$gba it says something like "Loading..."
I guess that means that it tries to load data from the flashcart's (unemulated) internal sd-card storage.
edo9300 wrote:
Yeah, i too was suspecting it was an hardware issue, now i'm asking myself if it's because of damaged components or some different chips of the ds. As for the firmware, i didn't do nothing of those things, i only installed unlaunch via flipnote and that's all, i didn't modify my nand in other ways. I could send pics of my console if needed
At the moment I suspect that I've screwed up something - so better wait before you try to desolder/repair your chips, they are probably all fine.
Ugh, I think I've tracked down the unstable part: nds/dsi titles are started with cache disabled, and unlaunch is also doing that before starting other titles - the problem is that the disabled cache does still seem to hold old data even when in disabled state, and that old data will 'mysteriously' reappear once when the loaded title (re-)enables the cache. Instead of just disabling the cache, correct way to disable+kill the cache content should be:
Code:
- clean data cache (writeback any write-buffered data from cache to actual memory)
- disable cache (while doing this, a few more bytes might get newly loaded into code+data caches)
- invalidate data+code caches (forget all cached data+code)
Without that, any kind of weird and not-so-funny effects can happen. One of the weirdest was arm9 hanging for about 10 minutes in a small memfill function (and then resuming normal execution after that 10 minutes). And the nastiest effects were those cases where everything seemed to work fine (making me think to have solved the issue a bunch of times - only to see the problem to reappear after making a few more unrelated code changes).
So, well, I hope I've now really fixed it. Will do a few more tests, and (if it keeps working), upload next version soon.
nocash wrote:
Robz8 wrote:
Found a bug when having homebrew named as "bootcode.dsi".
The power button doesn't work, if set to IRQ. It only works when setting it to Auto-Reset.
I don't recall the issue occurring in previous Unlaunch versions.
The last change to power button was in unlaunch v1.0 (switching it power-button-IRQ-mode) (the older versions had it set to power-button-auto-reset mode).
If IRQ mode doesn't work... maybe it does still have an old IRQ pending and refuses to issue a new IRQ until acknowledging the old one... by reading BPTWL register 10h? Or maybe the IRQ and pin-direction isn't configured in GPIO registers? Or something in IE2/IF2 registers?
Do you have a link to some homebrew title that shows the effect?
I believe all homebrew have this issue, including HiyaCFW (settings menu), DSiMenu++, and nesDS, which we're tested.
New version: Unlaunch v1.3 -
http://problemkaputt.de/unlaunch.htmI hope I've got everything stable this time.
Code:
v1.3 09 Aug 2018
- forces disabled cache to be MADE EMPTY before starting loaded title
- rearranged init sequence for loaded titles and added more cache flushes
- moved scfg state from 380FFCX to 3FFFFCX, passes final state to loaded title
- bugfix: skip wifi init by button Y (not button B, which is ROM cart loading)
- checks for unknown cid/csd AFTER manually reading cid/csd from hardware
Looks like the wifi issue for carts is fixed. Still couldn't run installer from Unlaunch. Blackscreens. But maybe just due to 1.2's issues. Was able to install it from sudokuhax as boot.nds.
Tried to boot Launcher as bootcode.dsi. Still white screens. Though if I hold Y to prevent wifi init I can see Launcher gets far enough to init wifi (wifi led still comes on, but a bit later). Maybe hanging due to device table being at wrong place since Launcher is a bit different then other DSiWare.
Apache Thunder wrote:
Still couldn't run installer from Unlaunch. Blackscreens. But maybe just due to 1.2's issues. Was able to install it from sudokuhax as boot.nds.
Yes, that should be caused by the old v1.2 version, and the problem should be gone once when having v1.3 installed.
To get rid of v1.2:
Boot to normal firmware (via button A) and then use sudokuhax or flipnote to load the v1.3 installer (as you did).
Or, rename hbmenu or wifiboot or the like to bootcode.dsi, and then use that to load the v1.3 installer.
I guess at least one of that methods should work on all consoles.
Apache Thunder wrote:
Tried to boot Launcher as bootcode.dsi. Still white screens. Though if I hold Y to prevent wifi init I can see Launcher gets far enough to init wifi (wifi led still comes on, but a bit later). Maybe hanging due to device table being at wrong place since Launcher is a bit different then other DSiWare.
Is the launcher using the incoming device list at all? I thought it would ignore the incoming list and instead create a device list on its own.
If v1.3 is working stable, then plans for next version would be adding some bootmenu to select different titles, without manually needing to rename titles to bootthis.dsi and then storing them on SD card (or SD-card image) in order to test them. That will make it easier to test/fix issues with launcher (or other titles).
Robz8 wrote:
I believe all homebrew have this issue, including HiyaCFW (settings menu), DSiMenu++, and nesDS, which we're tested.
Hmmm, that seem to be all available only from those open source sites that are available only via https. I could try downloading them on another PC and then transfer them to my own computer... or is the power-button problem already fixed in v1.3?
Seems to maybe use the device list from stage2 initially. I tried to boot unmodified Launcher as well and it still white screens.
nocash wrote:
Hmmm, that seem to be all available only from those open source sites that are available only via https. I could try downloading them on another PC and then transfer them to my own computer
What web browser are you using that can't browse HTTPS?
tepples wrote:
What web browser are you using that can't browse HTTPS?
I believe his main computer is still on Windows 98. Browsers that still run on that OS don't support HTTPS anymore I think.
IE in Windows 98 reportedly has an experimental (at the time) option to enable TLS 1.0, though that won't help with shopping and financial sites that don't fall back to old TLS anymore.
On my 9x machines I use RetroZilla for the sites that Opera can no longer open due to some security protocols related issue.
Weirdly enough... The 1,3 stil doesn't work
at this point i think it's my ds
TmEE wrote:
On my 9x machines I use RetroZilla for the sites that Opera can no longer open due to some security protocols related issue.
Thanks! I didn't knew that program. I thought Opera 10.53 was the newest browser working on win9x, but that's about 8-10 years old. Hmmm, downloading RetroZilla without https seems to be impossible ; ) okay, downloaded it on a laptop, and moved the installer to my PC...
It can access https gbatemp, but with the gbatemp java script adverts, it's endless slow, and the browser seems to have no option for disabling java script for certain webpages (it can only disable it for
all webpages).
As for other https sites: Sourceforge bugs saying that the webpage is empty. And github uses a "not enabled" https security protocol (I am using the latest RetroZilla version from 2017, which is itself being hosted on github - meaning that RetroZilla is unable to browse to its own homepage).
RetroZilla doesn't seem to be of too much use at the moment : / but thanks for mentioning it! Maybe it'll be useful for some other webpage someday (or maybe it gets updated and works better in next version).
edo9300 wrote:
Weirdly enough... The 1,3 stil doesn't work :( at this point i think it's my ds
The only thing not working for you is booting without sd-card inserted (or button A pressed), and then it hangs while displaying the unlaunch version number and attempting to load the original launcher, right?
I would assume that you have somehow lost your launcher ".app" file, or some other important system files. My guess would be about the issue from unlaunch v0.6, which could cause launcher to get deleted when accessing data managment, or dsi shop, or 3ds transfer tool - did you did that back then when v0.6 was out? Or did you try to upgrade/downgrade the firmware at some point after installing unlaunch?
If it's for one of the above reasons, then it could be repaired, and the same issue should also occur when testing in no$gba. Did you really test that, using a backup of your CURRENT emmc/nand, and renaming it to dsi-1.mmc, and using that in no$gba, with dsi mode enabled, and with the entrypoint set to BIOS mode, and then start some random dsi title? If yes, then you should see the unlaunch v1.3 screen, and then see the launcher (or it should hang in the unlaunch screen if the problem occurs in no$gba, too). If you just see the loaded game (without preceeding unlaunch and launcher screens), then you didn't test it properly.
Well, that are quite some steps, I am not sure if you really did all that stuff when testing - or if you had just tested a random game in no$gba, and then figured that "working game" is same as "working firmware image" (which isn't so).
For some general checks, you also dump your emmc, decrypt it with twltool, mount it, and then use scandisk to check for obvious errors, and check the launcher's content folder to see if it still has the .app and .tmd files, and the hwinfo files in other folders (gbatek has a list of files/folders that should be present, see the SD/MMC filesystem chapters).
I've got an issue where the installer always says I've "discovered unknown camera chip IDs" when I go to install unlaunch. It says to check for a newer version, but I am already using 1.3. Does anyone know what is going on?
Quote:
The only thing not working for you is booting without sd-card inserted (or button A pressed), and then it hangs while displaying the unlaunch version number and attempting to load the original launcher, right?
I would assume that you have somehow lost your launcher ".app" file, or some other important system files. My guess would be about the issue from unlaunch v0.6, which could cause launcher to get deleted when accessing data managment, or dsi shop, or 3ds transfer tool - did you did that back then when v0.6 was out? Or did you try to upgrade/downgrade the firmware at some point after installing unlaunch?
If it's for one of the above reasons, then it could be repaired, and the same issue should also occur when testing in no$gba. Did you really test that, using a backup of your CURRENT emmc/nand, and renaming it to dsi-1.mmc, and using that in no$gba, with dsi mode enabled, and with the entrypoint set to BIOS mode, and then start some random dsi title? If yes, then you should see the unlaunch v1.3 screen, and then see the launcher (or it should hang in the unlaunch screen if the problem occurs in no$gba, too). If you just see the loaded game (without preceeding unlaunch and launcher screens), then you didn't test it properly.
Well, that are quite some steps, I am not sure if you really did all that stuff when testing - or if you had just tested a random game in no$gba, and then figured that "working game" is same as "working firmware image" (which isn't so).
For some general checks, you also dump your emmc, decrypt it with twltool, mount it, and then use scandisk to check for obvious errors, and check the launcher's content folder to see if it still has the .app and .tmd files, and the hwinfo files in other folders (gbatek has a list of files/folders that should be present, see the SD/MMC filesystem chapters).
I first modded the dsi when the 0.9 version was out, even if i didn't install it because of the various issues and used the 0.8, later i tried installing the 0.9 and noticed it wasn't booting, after that i tried installing some older versions of unlaunch and i installed the 0.7 and the 0.6, and checked if they were working or not, the 0.6 did, but i then returned to the 0.8, i have 2 nand backups i'm testing with no$gba. The first from when i reported the issue in this forum and you told me to check (that backup had unlaunch 0.8 installed), the second when the 1.2 came out after it didn't boot (that had unlaunch 1.2 installed) on both the backups, both the 1.2 and 1.3 works. I installed the 1.3 on both the backups from no$gba. As for the files in the backup, they're there, both the app and title tmd, with the correct size.
nocash wrote:
Hmmm, that seem to be all available only from those open source sites that are available only via https. I could try downloading them on another PC and then transfer them to my own computer... or is the power-button problem already fixed in v1.3?
Nope, the problem is not fixed.
btw, I uploaded DSiMenu++, since you are unable to access the site for it.
XAYAH wrote:
I've got an issue where the installer always says I've "discovered unknown camera chip IDs" when I go to install unlaunch. It says to check for a newer version, but I am already using 1.3. Does anyone know what is going on?
When saying "using 1.3" do you mean that you already installed 1.3 successfully, or that you are trying to install 1.3?
In latter case, see here:
viewtopic.php?f=23&t=17581&start=30#p223062
I am trying to install 1.3 yes, however I'm not sure what is relevant to me in the post that you linked.
XAYAH wrote:
I am trying to install 1.3 yes, however I'm not sure what is relevant to me in the post that you linked.
Oh, sorry, asking if you were "trying to install" was misleading.
I meant this: If you are "trying to upgrade from an older unlaunch version" then the problem might be caused by a glitch in the older unlaunch version (and the linked post shows some workarounds). The problem there is that old unlaunch didn't empty the cache when loading bootcode.dsi (if your bootcode.dsi file contains the new unlaunch version, then the new version may fail to detect the cameras or run into other weird effects).
What are you using for using for installing unlaunch? Some exploit like Flipnote or Sudokuhax?
With some exploits it may be also helpful to insert hbmenu or wifiboot into the bootchain (ie. load one of that tools as boot.nds, and then use that tool to load the unlaunch installer).
All of the above is assuming that the unknown camera warning is shown only accidently. The other possibility would be that you do have uncommon camera hardware. All known consoles have two Aptina cameras (with ID=2280). The four values in the screenshot have this meaning:
Code:
FFFF 1st Aptina camera (usually 2280=the usual camera ID found in all known DSi's) (but your screenshot says FFFF=none)
2280 2nd Aptina camera (usually 2280=the usual camera ID found in all known DSi's)
FF 1st alternate camera from some other manufacturer (usually FF=none)
FF 2nd alternate camera from some other manufacturer (usually FF=none)
Going by that values your console would contain only one working camera instead of two. But I doubt that that's true (unless you say that your hinge is broken and there are some broken cables dangling out of the console).
I think it's more likely that the detection went wrong; as happening when trying to upgrade from 1.2 to 1.3, which sometimes causes camera values FFFF,FFFF,FF,FF to be displayed. Your values are a bit different, but my first guess was that it's nethertheless related to the same issue.
Robz8 wrote:
nocash wrote:
Hmmm, that seem to be all available only from those open source sites that are available only via https. I could try downloading them on another PC and then transfer them to my own computer... or is the power-button problem already fixed in v1.3?
Nope, the problem is not fixed.
btw, I uploaded DSiMenu++, since you are unable to access the site for it.
Got it downloaded, thanks!
Power button doesn't work because the IRQ isn't enabled in GPIO registers. From what I can see, the Launcher seems to enable that for you (and I'll do so in next unlaunch version, too). Additionally, commercial games seem to also enable the IRQ themselves (and should be perfectly legit if do that in homebrew titles too, ie. write [4004C02h]=4000h, so you won't need to wait for next update and/or want to have your program working like official games).
The exact official code in firmware v1.4E looks as so:
Code:
037B0F30 E1A04000 mov r4,r0
037B0F34 EBFEAD1E bl 375C3B4h ;lau7_cpsr_disable_irq
037B0F38 E1A05000 mov r5,r0
037B0F3C EBFEB43D bl 375E038h ;lau7_get_gpio_irq_config ;\
037B0F40 E3C00040 bic r0,r0,40h ;
037B0F44 E1A00800 mov r0,r0,lsl 10h ; enable
037B0F48 E1A00820 mov r0,r0,lsr 10h ; powerbutton
037B0F4C E3800901 orr r0,r0,4000h ;power.butt.irq ; irq
037B0F50 E1A00800 mov r0,r0,lsl 10h ;
037B0F54 E1A00820 mov r0,r0,lsr 10h ;
037B0F58 EBFEB432 bl 375E028h ;lau7_set_gpio_irq_config ;/
037B0F5C E3A00901 mov r0,4000h ;mask ;\set powerbutton
037B0F60 E3A01000 mov r1,0h ;set (none, aka clear) ; direction
037B0F64 EBFEB419 bl 375DFD0h ;lau7_read_modify_gpio_data_io ;/to 0=input
037B0F68 E1A00005 mov r0,r5
037B0F6C EBFEAD15 bl 375C3C8h ;lau7_cpsr_restore_irq
Touchscreen doesn't work, too (as far as I remember you mentioned that somewhere, too). One think that looks wrong is your cartheader entry [1BFh], that's setting the touchscreen to NDS mode, or is that intended as so? Once when it's in NDS mode, I don't know of way to switch touchscreen back DSi mode (except by issueing a Reset with complete reboot).
nocash wrote:
Touchscreen doesn't work, too (as far as I remember you mentioned that somewhere, too). One think that looks wrong is your cartheader entry [1BFh], that's setting the touchscreen to NDS mode, or is that intended as so? Once when it's in NDS mode, I don't know of way to switch touchscreen back DSi mode (except by issueing a Reset with complete reboot).
Yeah I believe they intentionally do that to ensure touch screen works once NTR mode games are running. They tried to mode switch the touchscreen some time back. I recall there was issues so right now they don't do that anymore. Right now the only downside is lack of touch control in the menu. If only libnds allowed forcing ntr mode touchscreen code in TWL mode....
It's not an upgrade at all, I'm trying to install unlaunch for the first time on this console. I guess it's possible that one of the cameras has been disconnected, I have had to take it apart once or twice due to some screen issues. The camera app does crash when I try to open the camera so that would make sense. I am trying to install using flipnote, which is already booting hbmenu which I am using to open the unlaunch installer.
XAYAH wrote:
It's not an upgrade at all, I'm trying to install unlaunch for the first time on this console. I guess it's possible that one of the cameras has been disconnected, I have had to take it apart once or twice due to some screen issues. The camera app does crash when I try to open the camera so that would make sense. I am trying to install using flipnote, which is already booting hbmenu which I am using to open the unlaunch installer.
Ah, okay, if the official DSi camera tool doesn't work either then it's apparently really a hardware issue, not a bug in unlaunch.
You could install unlaunch v0.8 (which didn't have the camera check), I think/hope that v1.3 is a bit more stable when v0.8, but v0.8 seems to have worked okay for most or all people, so it should be quite safe, too. Or you could install v1.3 manually (eg. via hardmod). Or I could maybe add something for detecting your broken hardware, and let it pass to the installer for that specific situation.
Might be worth opening the console and check what's wrong with it. But the ribbon cables for the two cameras are both connected to the same connector (P9), and (apart from the camera LED) both cameras are sharing the exact same signals, so the issue is probably not caused by a loose connector (as that would affect both cameras). I would be afraid that it's a broken ribbon cable, or some damage to the actual camera, ie. things that are quite impossible to repair (unless it's something simple like some metal junk touching the camera contacts & producing a shortcut; or maybe a blown fuse, if there are any fuses in there). Quite possible that you would need to replace the whole ribbon cables with attached cameras and connector.
Apache Thunder wrote:
Yeah I believe they intentionally do that to ensure touch screen works once NTR mode games are running. They tried to mode switch the touchscreen some time back. I recall there was issues so right now they don't do that anymore. Right now the only downside is lack of touch control in the menu. If only libnds allowed forcing ntr mode touchscreen code in TWL mode.... :P
Yeah, libnds should probably support that, at least Nintendo is apparently supporting DSi titles to use NDS-TSC mode (don't know if they've every released any titles doing that though).
On the other hand, switching to NDS-TSC mode just requires the following code (which will also fix the power button issue) (the init list & send list functions are found in the dsloader.a22 source code file in wifiboot.zip available on the unlaunch webpage) (for NDS titles that do not have an actual DSi header, make sure that you set dsi header [1BCh] to 00000000h).
Code:
ldr r1,=__DSiHeader ;\
ldr r0,[r1,1bch] ;hdr[1BCh] ; switch to NDS TSC mode
tst r0,1000000h ;bit24=tsc mode ; (if requested in cart header)
ldr r1,=nds_mode_tsc_init_list ;
bleq send_tsc_list_r1 ;/
ldr r1,=4004C00h ;GPIO ;\
ldr r0,=8080h ;bit7 dta+dir ; REQUIRED for flipnote SOUND output
strh r0,[r1] ;set new ;/
ldr r1,=4004C02h ;GPIO ;\REQUIRED for homebrew titles
ldr r0,=4000h ;powerbutt irq enable ; (commercial titles do that themselves,
strh r0,[r1] ;set new ;/incoming value from launcher is 4000h)
edo9300 wrote:
I first modded the dsi when the 0.9 version was out, even if i didn't install it because of the various issues and used the 0.8, later i tried installing the 0.9 and noticed it wasn't booting, after that i tried installing some older versions of unlaunch and i installed the 0.7 and the 0.6, and checked if they were working or not, the 0.6 did, but i then returned to the 0.8, i have 2 nand backups i'm testing with no$gba. The first from when i reported the issue in this forum and you told me to check (that backup had unlaunch 0.8 installed), the second when the 1.2 came out after it didn't boot (that had unlaunch 1.2 installed) on both the backups, both the 1.2 and 1.3 works. I installed the 1.3 on both the backups from no$gba. As for the files in the backup, they're there, both the app and title tmd, with the correct size.
Thanks for the screenshots. Yes, looks as if you really have no$gba configured as needed. I am running out of ideas why it isn't working the same way on real hardware. Except, you could try to dump CURRENT eMMC content (as far as I understand you've installed v1.3 independently on hardware and in no$gba, so the dump may be still slightly different than real hardware).
If you had v0.9 installed first, then the launcher files were already write-protected (so later use of v0.6 won't cause any harm).
Did you try to hold down button Y in v1.3 to skip wifi init (or both Y+A, if you have sd card inserted)? Maybe that helps, though I wouldn't know why, unless you have some different wifi hardware than most people. Maybe it's really time to look at the mainboard and chipset. Aside from different wifi boards, there seem to be different BPTWL chips, and different sound/touchscreen controllers.
Well, or I could make a version with additional boot status messages, or with blank red/green/blue screens during the patched-launcher boot stages. That'd help to find out where it's hanging exactly.
Ah, and did you try hiyacfw? As far as I know, that's also booting into the official launcher, with similar patches as in unlaunch. Does that hang, too?
PS. I do currently have firmeware v1.4E on my console, and tested v1.4.5E only in no$gba, so I didn't check if v1.4.5E would hang on my console, too. But I guess a lot of other people have tested that and it's working without problems... If somebody has firmware v1.4.5E and unlaunch v1.3 installed: Could you test/confirm if it's working or hanging (when ejecting the SD card, or holding down button A during boot)?
nocash wrote:
edo9300 wrote:
I first modded the dsi when the 0.9 version was out, even if i didn't install it because of the various issues and used the 0.8, later i tried installing the 0.9 and noticed it wasn't booting, after that i tried installing some older versions of unlaunch and i installed the 0.7 and the 0.6, and checked if they were working or not, the 0.6 did, but i then returned to the 0.8, i have 2 nand backups i'm testing with no$gba. The first from when i reported the issue in this forum and you told me to check (that backup had unlaunch 0.8 installed), the second when the 1.2 came out after it didn't boot (that had unlaunch 1.2 installed) on both the backups, both the 1.2 and 1.3 works. I installed the 1.3 on both the backups from no$gba. As for the files in the backup, they're there, both the app and title tmd, with the correct size.
Thanks for the screenshots. Yes, looks as if you really have no$gba configured as needed. I am running out of ideas why it isn't working the same way on real hardware. Except, you could try to dump CURRENT eMMC content (as far as I understand you've installed v1.3 independently on hardware and in no$gba, so the dump may be still slightly different than real hardware).
If you had v0.9 installed first, then the launcher files were already write-protected (so later use of v0.6 won't cause any harm).
Did you try to hold down button Y in v1.3 to skip wifi init (or both Y+A, if you have sd card inserted)? Maybe that helps, though I wouldn't know why, unless you have some different wifi hardware than most people. Maybe it's really time to look at the mainboard and chipset. Aside from different wifi boards, there seem to be different BPTWL chips, and different sound/touchscreen controllers.
Well, or I could make a version with additional boot status messages, or with blank red/green/blue screens during the patched-launcher boot stages. That'd help to find out where it's hanging exactly.
Ah, and did you try hiyacfw? As far as I know, that's also booting into the official launcher, with similar patches as in unlaunch. Does that hang, too?
PS. I do currently have firmeware v1.4E on my console, and tested v1.4.5E only in no$gba, so I didn't check if v1.4.5E would hang on my console, too. But I guess a lot of other people have tested that and it's working without problems... If somebody has firmware v1.4.5E and unlaunch v1.3 installed: Could you test/confirm if it's working or hanging (when ejecting the SD card, or holding down button A during boot)?
Tested all those various things, but 1.3 is beheaving as the same way as 1.2, so cannot acess teh system nand, via unlaunch, or the sdnand via hiya cfw. There's still also the issue with games with wifi capabilities that are still not booting with b pressed, while the other are. Those games are pokemon platinum, pokemon white and yugioh gx spirit caller. the ones that boot instead are mario bros, lotr aragorn's quest and transformers the dark side of the moon autobots. Also i have a flashcard with wifi capabilities, with b pressed it boots, but as soon as i enter the wifi settings it freezes on a black screen.
Also in the dsi homebrew discord server, I noticed that I'm the only one with a dsi xl on 1.4.5 e that doesn't boot with unlaunch 1.3
After several emails with nocash about unkown emmc/cid errors with unlaunch, he asked me to upload a picture of my nand here.
Thank you! Good to see how that chip looks like for real! If somebody else is reading this: The CID/CSD values shown in unlaunch's unknown hardware warning, for this chip on the above phote are:
Code:
1D XX XX XX XX 31 36 35 ;\CID
32 43 4D 4D 4E 01 FE 00 ;/
00 40 8A E0 BF FF 7F F5 ;\CSD
80 59 0F 32 01 2F 90 00 ;/
80 80 FF 80 00 04 00 00
00 00 00 00 01 00 01 00
00 00 00 00 00 00 00 00
00 09 00 00 00 01 D0 40
00 00 01 00
And, about a hour later after receiving that values, I got screenshot with similar values from somebody else:
https://i.imgur.com/embuZyj.jpg (with same values as above, except with date code CC instead of 1D in first byte).
That chips are almost same as this one
viewtopic.php?f=23&t=17581&start=15#p222497 discovered a few weeks ago. The difference (apart from date code) is the 6th byte of the CID being 31h instead of 30h. That byte is supposed to contain the chip revision number. The values are looking like ASCII for rev1 and rev0... although going by official MMC specs they suppose to be BCD values, with 31h and 30h meaning rev3.1 and rev3.0.
Anyways, they are different revisions. Ah, and one reason for mentioning those difference here is that people without Flipnote will often need to brute-force their CID before installing code on the DSi console, so the above will help them to find out which values they are searching for.
Just looking at the chip photo, I can't see anything indicating the revision number on them. The first lines with "ST, NAND02G, AH0LZC5" are same, the next line contains some different letters/digits, and the last 3 digits in last line are also different (those might be a YWW date code with year/week values, but, if so, then the YWW value on the chip is several weeks older than the month/year value in the CID).
nocash wrote:
XAYAH wrote:
It's not an upgrade at all, I'm trying to install unlaunch for the first time on this console. I guess it's possible that one of the cameras has been disconnected, I have had to take it apart once or twice due to some screen issues. The camera app does crash when I try to open the camera so that would make sense. I am trying to install using flipnote, which is already booting hbmenu which I am using to open the unlaunch installer.
Ah, okay, if the official DSi camera tool doesn't work either then it's apparently really a hardware issue, not a bug in unlaunch.
You could install unlaunch v0.8 (which didn't have the camera check), I think/hope that v1.3 is a bit more stable when v0.8, but v0.8 seems to have worked okay for most or all people, so it should be quite safe, too. Or you could install v1.3 manually (eg. via hardmod). Or I could maybe add something for detecting your broken hardware, and let it pass to the installer for that specific situation.
Might be worth opening the console and check what's wrong with it. But the ribbon cables for the two cameras are both connected to the same connector (P9), and (apart from the camera LED) both cameras are sharing the exact same signals, so the issue is probably not caused by a loose connector (as that would affect both cameras). I would be afraid that it's a broken ribbon cable, or some damage to the actual camera, ie. things that are quite impossible to repair (unless it's something simple like some metal junk touching the camera contacts & producing a shortcut; or maybe a blown fuse, if there are any fuses in there). Quite possible that you would need to replace the whole ribbon cables with attached cameras and connector.
I opened it and didn't see anything obviously wrong with the cameras or the ribbon cable so it is probably something wrong inside one of them or something. I just installed 0.8 and it is working! Thank you
Slightly unrelated: From what I've heard, people still don't know how to write to eMMC in a stable way (and if that's true, then I suspect that SD writes are equally unstable since they use the same sector writing mechanism). So here some of my findings and ideas:
Timeouts
Some DSi sd/mmc writing functions seem to contain timeout counters (and I had used something similar up to including unlaunch v0.9). I think that timeout handling should be completely removed.
First of, the sd/mmc controller is generating its own error flags (including timeouts), and it's better to use that flags instead of using manually generated timeouts (ie. check error flags alongsides with ready flags when reading SD_IRQ_STATUS). With manually generated timeouts things could derail badly (eg. software aborting write while hardware is still trying to finish writing).
Second, some writes may be slower than expected (writing to worn-out sectors may be slower, and if the sector dies completely then broken-sector replacement will occur, which will make the write even slower). So, regardless of the timeout mechanism used, the timeout must be large enough for worst-case write timings.
Officially, worst case timeout should be somehow computed from the CSD register, but I am just using a fixed setting of SD_CARD_OPTION=40D0h, which should work with all eMMC chip variants used in the DSi (I haven't tried writing anything to 3DS or to SD cards, but I hope 3DS is also fast enough to work with that value, whilst, for external for SD/MMC cards, it might depend on whether it's an old/new slow/fast card). Ah, and for special cases, one might need much larger timeouts (eg. when/if using erase-multiple-sector commands).
Error handling
Yeah, to be honest, despite of checking the error flags in SD_IRQ_STATUS, I am not really having an error handler for them - because I think that timeouts and other errors should never happen during normal operation (exceptions would be ejecting an SD card during access, or writing to a totally dead worn-out card, or sending an unsupported command, or using too small values in SD_CARD_OPTION, or the like).
Nethertheless, of course it wouldn't be bad to implement some error handling. Though I am unsure what to do best in which situation... A fatal error blue screen would be better than silently ignoring the error. In some cases it might help to retry sending the command a few times, or to prompt the user whether to retry/ignore/cancel, or to re-insert the ejected card. And maybe one might want to try to keep finishing further writes before locking up in fatal error screen. And, one would somehow need to implement showing the prompt's or error messages in the user interface, which may be easy or difficult, depending on how the existing user interface looks like (eg. wheter currently displaying a text screen, or animated graphics layers).
Well, and aside from SD_IRQ_STATUS flags (errors spotted by the sd/mmc controller), one should also check flags in CSR register (errors spotted by the sd/mmc storage chip itself). I am not actually doing that either, and I am vaguely remembering that there might be special cases like errors for the current command not being reported until after sending the next command (Nintendo seems to send a separate GET_STATUS command after each READ/WRITE_MULTIPLE command, maybe for that reason).
Restoring eMMC backups
Most important should be comparing the (encrypted) MBR's on sector 0 of the eMMC chip with that from the MMC image, if they don't match up then the MMC image is from a different console, or it's a decrypted image - which would both brick the console.
Be sure to support both Samsung 240Mbyte and ST 245.5MByte images, and if there's the 40h-byte no$gba footer appended at the end of the image, omit those last bytes when writing. For 245.5MByte chips: I don't know if existing DSi tools support making a full backup of those chips though.
As it'll take some time to write the whole image, it may be extra important to check battery level before starting, and to ignore power button irq during writing, and of course to display some progress bar & ready message.
And a special caution related to DSi shop: If the console had never accessed the shop at time when making the eMMC backup, then accessing the shop (creating the dev.kp file), and then restoring the backup (without dev.kp), then the shop is reportedly getting confused, and you can't any longer access the shop from your console (of course, the shop is now mostly closed anyways, and you'd only loose access to the 3DS transfer tool).
Uninstalling unlaunch
Well that's the reason why I had wondered about eMMC writing issues at all. The official way to uninstall unlaunch would be truncating the launcher's .tmd file back to 520-byte size, and strip the read-only attributes for both .app and .tmd file (or restore a complete eMMC backup), but there appear to be no tools capable of doing that in a stable fashion yet (apart from hardmods).
The reasons why I haven't implemented an uninstall function myself are that it would convert the console back to the useless original state with the health safety touch to continue nag screen. And, my own ASM coded FAT engine is still a bit limited in functionality (it can increase the .tmd filesize with new clusters appended as needed, but it can't yet decrease the filesize and deallocate old clusters, and also can't delete/create files or such things).
EDIT: Also see apache's next post. If the console boots up okay with-unlaunch and without-sd-card-inserted, then you can probably safely truncate .tmd to 520-byte size, otherwise you'll carefully need to repair more things about getting an intact and matching launcher .app/.tmd pair. That issues may occur if you had used unlaunch v0.6, or if have somehow tried to upgrade/downgrade/region-change your launcher version.
Another factor about uninstalling Unlaunch could produce unsafe conditions. If Launcher.app was corrupted/swapped out/changed or the first part of the TMD was modified outside of Unlaunch's knowledge. So blindly truncating TMD back without first verifying that the TMD/Launcher pair would be valid would result in a brick from Stage2 rejecting it. Could be mitigated by requiring user provide the valid files needed to restore then rather then trying to fix what's already there.
As for the other issues. I never really thought about the underlying hardware. Thought the software took care of that. But I can see where things could go wrong. I've done a few full nand restores with a modified build of fwtool back when I was testing/working on RocketLauncher. Lack of decent nand tools was why RocketLauncher was never released. One of the only devs able to work on this was busy with other things so it was just held back by that. Anyways, even before reading your notes on this, I stopped using fwtool. Mainly because I don't need to touch nand again. Unlaunch seems perfectly fine installing to it and since it disables white list check, I haven't even gotten around to uninstalling the "RocketLauncher" version of the white list. Though even so, I have no reason to even without Unlaunch as I have no plans on ever changing nand's FW version from 1.4.
I'm wondering how the 3DS arm9 tools work. (stuff like GodMode9/Decrypt9). You should look at them. They use arm9 to handle SD/MMC stuff. (as long as 3DS is kept in CTR mode. Legacy mode switch results in arm9 losing access to SD/MMC and having arm7 handle it like on DSi) I'm curious if those are also coded to handle the things you've mentioned.
Hello! I hope this is the right place -- I didn't really know where else to put this. I'm having trouble with unlaunch and starting the rom cartridge on boot. It doesn't seem to work with my "R4i Gold 3DS Plus" -- it just hangs at a black screen? I'm using a DSi with unlaunch v1.2
Hello, not sure if anybody reported this problem yet: holding A to boot into sysNAND works maybe twice in 10 tries, most of the time it just freezes indefinitely and I have to force power off. This happens on every unlaunch version aside from 0.8, that one works every single time.
Everything aside from this works perfectly fine, using HiyaCFW and bootthis.dsi and such. I'm using a 1.4.5E normal-size DSi console, later downgraded to 1.4E but that didn't help. I've dumped the NAND and tried replicating the issue with No$GBA to no avail, emulated it works every single time. Both cameras are working perfectly fine in the DSi camera app.
highmans wrote:
Hello! I hope this is the right place -- I didn't really know where else to put this. I'm having trouble with unlaunch and starting the rom cartridge on boot. It doesn't seem to work with my "R4i Gold 3DS Plus" -- it just hangs at a black screen? I'm using a DSi with unlaunch v1.2
That feature also doesn't work with my R4i Gold 3DS, works fine with the oldest R4 though.
New update, unlaunch v1.4 -
http://problemkaputt.de/unlaunch.htmCode:
v1.4 22 Aug 2018
- web: created no$project patreon page, https://www.patreon.com/martin_korth
- added dpad UP hotkey: show red/blue/green to indicate relauncher bootstages
- added dpad DOWN hotkey: do NOT invalidate cache on startup of installer
- invalidates/forgets cache on startup of installer (unless hotkey, see above)
- initializes GPIO powerbutton irq enable (for some homebrew dsi titles)
- removed warning on unknown CID/CSD for ST NAND02GAH0LZC5 rev31 eMMC chips
Also new, there's a patreon page for my projects,
https://www.patreon.com/martin_korthDon't know if it'll bring in any money, but it would be nice, I am meanwhile totally bankrupt : /
Anyways, other things:
Booting the original launcher via button A works perfectly stable for me. Some older unlaunch versions did completely hang when running launcher on firmware v1.4.5, but then that should have happened always. I've never heard of situations where it's working in 2 of 10 cases.
In the new version, you can hold down DPAD UP (together with Button A), that will output some color codes on upper screen, that will give some hint at which bootstage it's hanging. You should see the unlaunch gif for a short moment, then RED blank screen, then BLUE, then GREEN, and finally a WHITE screen (with the original launcher gui appearing).
Caution: Please keep DPAD UP pressed all time (the colors are updated only while the button is pressed, if you release it while seeing the RED screen then it'll stay at that color even when reaching the stages where it should show blue/green).
R4i or the like... yeah, I can support them, if somebody buys one of that carts for me.
nocash wrote:
In the new version, you can hold down DPAD UP (together with Button A), that will output some color codes on upper screen, that will give some hint at which bootstage it's hanging. You should see the unlaunch gif for a short moment, then RED blank screen, then BLUE, then GREEN, and finally a WHITE screen (with the original launcher gui appearing)
Thank you for the quick response! When it hangs, it always does so on the RED screen.
Whew, I actually got a $5 patron : )
gabo12 wrote:
nocash wrote:
Thank you for the quick response! When it hangs, it always does so on the RED screen.
Okay, that's tracking it down a little. The colors are shown in this order:
- RED shown shortly before restarting stage2 (the code from boot sectors, which should be still residing intact in memory).
- stage2 is then doing some initialization and loading the launcher to memory
- BLUE shown when patches in stage2 are forwarding further patches to the launcher
- GREEN shown when having finished that patching
- stage2 is then doing some more stuff and does then actually start the launcher
- launcher is then doing a lot more stuff like wifi init and touchscreen init and showing user interface
So well, it does apparently hang while still in stage2 and before starting the launcher. That's a bit unexpected because stage2 doesn't do too many hardware specific things other than loading the launcher files from eMMC, and no firmware specific things other than encountering different filesizes when loading different launcher versions.
Hmmm, yeah, I guess it must be some timing/initialization issue making your console tend to behave a bit differently than others. I could add some CRC check on the stage2 code to make sure that it's really still intact in memory (and reload it from eMMC if needed, just in case it got destroyed somehow when originally triggering the exploit). On the other hand, I could also get rid of using stage2 completely, and instead load the launcher directly on my own - which probably requires only a little bit of testing and adding 1-2 small details to get it working.
Just updated, and with the debug colors, it remains stuck on red
nocash wrote:
Whew, I actually got a $5 patron : )
2 now....
Just wanted to tell you i love your work, i've been following you since NO$GMB, i used it on a 386 SX 33 Mhz with a Hercules graphics card (damn, how old i am).
Be well bro. And THANKS.
Clonardo.
Hello nocash, I get this error (v1.0 to 1.4), but I could assure that it is because my camera socket is damaged and that is why it is not detected, will it be possible to fix that in some update? Is this verification so necessary?
With regards to the R4i Gold 3DS -- I could send you mind to test, but I'd prefer to have it back if possible... Is there any information I could dump from the cart and provide you or does it require specialized hardware/software?
Most modern DS flashcarts spoof existing game roms. There's not much you can do in that case. You can either send him the header of the SRL of the rom dump you made from the flashcart or tell him the game/came code so he can find the rom and check it. A full rom dump would most likely not be much different then the actual game it was spoofing. (or a stripped down version of the game with a modified NitroFS section.
It's most likely a hardware issue where the flashcart isn't responding fast enough to certain commands or not quite behaving like a real retail cart in some way. He'll have to have the cart himself to test to find the issue as it's not really something one can test on No$GBA.
Though one idea is to add a debug color system for it much like with 1.4 adding it for testing issues with loading stage2/Launcher. Do one for the cart loader too. it could help maybe debug issues with some carts without having to go out and buy/donate them.
Regarding the carts I have, not sure if this helps or anything, but I did have to disable Secure Area checking in NTR Launcher before my DS-Xtreme would boot. The way the cart is handling that may not be quite up to spec with retail carts so NoCashe's code may be bugging out with it too if it works in any way similar to NitroHax's cart loading code which is what NTR Launcher is currently using. NTR Launcher can't handle any TWL carts though so I wouldn't have any idea why my Cyclo iEvo cart won't boot.
The Secure Area issue being resolved may fix quite a few flashcarts. I recall people reporting a lot of other carts working with NTR Launcher after I made that change to make my DS-X bootable.
Hey, I would just like to ask if you could add a hotkey to boot a file called, let's say bootme.dsi I know that there is already one for bootthis.dsi but Robz8 DSiMenu++ uses that to boot DSiWare, meaning you can't use it for anything else unless you stop using DSiMenu++ or start using .launargv files.
I can confirm that I have exactly the same issue as gabo12 when I hold A button it hangs on unlaunch screen latest release and dsixl 1.4.5e. Had same problem on v0.9. when I hold A and Up button it stays on red too.
Also a weird issue when running DSiware renamed to boothis.dsi on the root of the SD card the games Warioware Touch and Jeckyl and Hyde have no sound yet if I use the normal method to run them through the dsimenu they work absolutely fine. All the House MD games hang with black screen and bgm in endless loop. Again these games work fine with the normal method. I presume this is an issue with Unlaunch as unlaunch is trying to run those ROMs renamed to BOOTTHIS.DSI (I capitalized that because of the pedantic coments)holding X button while console boots. I removed everything of dsimenu++ from my SD card and put only a dsiware ROM renamed to BOOTTHIS.DSI and turned the console on while holding the X button. As I already mentioned those particular games have strange behaviour. All other DSiware ROMs work fine (with sound and no hangs). I posted this as a bug report because it obviously is something of a bug and you invite everyone to comment using this forum or email you. Oh well won't be bothering any more. Good luck with your project.
clonardo wrote:
nocash wrote:
Whew, I actually got a $5 patron : )
2 now....
Just wanted to tell you i love your work, i've been following you since NO$GMB, i used it on a 386 SX 33 Mhz with a Hercules graphics card (damn, how old i am).
Be well bro. And THANKS.
Thank you, too!
And also thanks to the third person having joined the
https://www.patreon.com/martin_korth page!
Racso55 wrote:
Hello nocash, I get this error (v1.0 to 1.4), but I could assure that it is because my camera socket is damaged and that is why it is not detected, will it be possible to fix that in some update? Is this verification so necessary?
That's intended for identifying the unknown cameras, I think it's somewhat important (if nintendo has ever manufactured any consoles with those cameras).
But as it looks now, it appears to be more common to find people with broken camera(s). That's good to know, too. So best advice to game developers would be to "keep your games playable despite of broken cameras - that seems to be more important than supporting unknown cameras".
In unlaunch, I can change it to show the warning only on unknown ID values (but ignore missing ID's with value FFFF/FF). Btw. how are you destroying the camera/connectors?
highmans wrote:
With regards to the R4i Gold 3DS -- I could send you mind to test, but I'd prefer to have it back if possible... Is there any information I could dump from the cart and provide you or does it require specialized hardware/software?
I guess it's hardware related... if I could get and keep one of those carts would be best... especially if I happen to need to do more tests with it in future.
mrkrabs wrote:
Hey, I would just like to ask if you could add a hotkey to boot a file called, let's say bootme.dsi I know that there is already one for bootthis.dsi but Robz8 DSiMenu++ uses that to boot DSiWare, meaning you can't use it for anything else unless you stop using DSiMenu++ or start using .launargv files.
Maybe yes, though the hotkeys are already quite a mess, but I can probably remove some of them in future.
Sion.zaphod wrote:
Also a wired issue when running DSiware using dsimenu++ Warioware Touch and Jeckyl and Hyde have no sound yet if I use the argv method to run them they work absolutely fine. All the House MD games hang with black screen and bgm in endless loop. Again these games work fine with the argv method. I presume this is an issue with Unlaunch as unlaunch is trying to run those ROMs renamed to runthis.dsi by holding X button while console reboots.
I don't really understand the sentence. I didn't make dsimenu++, and I don't have those games, and I don't know anything about an argv method, or about runthis.dsi.
I've just tried loading the launcher directly from eMMC (just like loading bootcode.dsi from SD card). It seems to be working without problems... aside from loading the file it seems to require (parts of) the device list: The ".app" name seems to be needed. And all other device list entries seem to be generated by the launcher itself.
Not sure why it can't load the launcher from SD card... the main issue seems to be "sdmc" not being included in the device list... maybe that could be fixed by adjusting the launcher's cart header (if the launcher is using it's own header to determine whether it wants to create the "sdmc" device or not).
nocash wrote:
Racso55 wrote:
Hello nocash, I get this error (v1.0 to 1.4), but I could assure that it is because my camera socket is damaged and that is why it is not detected, will it be possible to fix that in some update? Is this verification so necessary?
That's intended for identifying the unknown cameras, I think it's somewhat important (if nintendo has ever manufactured any consoles with those cameras).
But as it looks now, it appears to be more common to find people with broken camera(s). That's good to know, too. So best advice to game developers would be to "keep your games playable despite of broken cameras - that seems to be more important than supporting unknown cameras".
In unlaunch, I can change it to show the warning only on unknown ID values (but ignore missing ID's with value FFFF/FF). Btw. how are you destroying the camera/connectors?
In my case it was because the insurance was toasted of the old, others that I have known was due to lack of technician and as they do not give importance they leave it this way, thanks for answering! I'll be waiting for the update
Since my sentence was grammatically incorrect I revised it in the original post
Okay, now I understand what you mean. Yes, agreed, that really seems to be an issue in unlaunch.
I guess you made sure providing bootthis.pub and/or bootthis.prv as needed. Some other things that might relate to sound issues...
What value do you have in cart header [1BFh]? The touchscreen/sound controller mode in bit0 could affect sound. And the banner.sav flag in bit2 might cause weird effects if the banner.sav file doesn't exist (and I've no idea which device:/path it would use for the banner.sav file; especially in combination with the device list being redirected to sdmc:/bootthis.xxx).
If you feel like debugging your sd and mmc images in no$gba:
A look at the "Sound7" page in I/O map window would help (to see if there are any voices sent to the sound channels, if so, then inaudible sound might be caused by something muting audio amplifier or master volume).
Or if no$gba is bugging about writes to the DSP registers at 40043xxh, then the game might use the Teak DSP for sound output (the launcher is doing some minimal initialization for that; maybe I should do that, too).
Quick update, i tried with 1.4 launching with nothing inserted and y pressed, out of 20 tries, it boted once
edo9300 wrote:
Quick update, i tried with 1.4 launching with nothing inserted and y pressed, out of 20 tries, it boted once
Sounds similar to what gabo12 had said (there working twice in 10 tries). Do you know if you
needed to have button Y pressed to get it working at least once?
Would be interesting to see what chipset you have on the mainboards/wifiboards. Especially if it turns out that you are both having the same/uncommon chips.
---
About Teak DSP: I've tried booting DSi Sound for testing if there are DSP issues... and it does have at lease
some issues...
First of, it hangs with blackscreen (still in unlaunch, before even starting the DSi Sound binary). The reason is that one of the modcrypt areas is extremly huge. It's exceeding the hardware's 16bit AES block counter, so one must split it into smaller blocks before decryption (and increase the IV manually alongsides).
And after fixing that, it now hangs in white screen (ie. the binary is started, but hangs before displaying anything else than white). Trying to init the DSP clock/reset/control registers doesn't seem to help. One uncommon thing is that DSi Sound (and Flipnote) are using the shared2\0000 file, but I don't think that that is causing the problem.
Running Unlaunch with DSi Sound in no$gba works better (apart from expected issues about the DSP not being emulated). So well, that'll be a bit difficult to find what goes wrong on hardware and why it isn't going wrong in no$gba... I guess it's some hardware issue, maybe DSP related, or maybe something else.
Are there other DSi(ware) games known to use Teak DSP, and do they work with unlaunch? The only two other titles known to me are Cooking Coach and Nintendo Zone... which well, I guess could test them myself with some effort (uninstalling the cooking exploit, or trying to start the (normally hidden) Nintendo Zone tool manually).
nocash wrote:
edo9300 wrote:
Quick update, i tried with 1.4 launching with nothing inserted and y pressed, out of 20 tries, it boted once
Sounds similar to what gabo12 had said (there working twice in 10 tries). Do you know if you
needed to have button Y pressed to get it working at least once?
Would be interesting to see what chipset you have on the mainboards/wifiboards. Especially if it turns out that you are both having the same/uncommon chips.
I tried without Y pressed but no luck, while it booted once with it pressed. Attached there are the pics of the wifi board and the nand chip
I meet a new weird bug. my friend has newly install unlaunch.
after he install 1.4, he cant boot into sysnand via press A with power on
but it can boot while press A + UP
Hi, @nocash,
I'm not sure if anybody has reported this problem yet: I've been using unlaunch + HiyaFCW on both a DSi and a DSi XL console for some time now. Recently, I created a downgraded NAND for each console with fwTool v1.6.1 --I wanted them to be on system 1.4E-- and then restored these new NANDs (they work fine if restored through fwTool v1.6.1).
From then on, I can install any version of unlaunch (I tried 0.8, 0.9 and 1.3 so far) and all these versions seem to install fine, however, they do nothing. When I reboot the consoles, the usual system is loaded. I cannot launch anything through bootcode.dsi, since this file is completely ignored (?). So, I can't install HiyaCFW or DsiMenu++ anymore. Why is this so strange behaviour happening? Maybe the .tmd in the NAND can't be modified anymore? Is it right-protected? But that should not matter if you want to update unlaunch, right? And why does unlauch (apparently) installs fine, but then the console acts as if unlaunch was NOT present?? The key combinations at boot time do nothing either.
UPDATE: I think unlaunch is not actually installed. I dumped the NAND after 'installing' unlaunch, and the launcher .tmd file is still 520 bytes, so it has not been modified at all!
UPDATE 2: Now I know what is the issue about not being able to install unlauch normally. If you downgrade a nand copy (for instance, from 1.4.5E to 1.4E), something happens to the launcher title that makes it impossible to install unlaunch through its installer (it seems to install, but it actually doesn't). What happens to the downgraded launcher title??
Any suggestions about how to make unlaunch work as it should again?
I'm out of ideas right now and a bit desperate because I can't figure out what is going on.
Thank you in advance for your help.
satelman wrote:
I can install any version of unlaunch (I tried 0.8, 0.9 and 1.3 so far) and all these versions seem to install fine, however, they do nothing.
Reminds me about this:
https://gbatemp.net/threads/my-nintendo ... -8.516016/That ended up with the person saying to know what was wrong, whatever that was (myself, I've no idea what was wrong).
Oh, and you've posted this here
https://gbatemp.net/threads/unlaunch-ds ... st-8298477 saying "not changed at all in the 484e4150 (EUR) folder, but a new folder, 484E4145 (US), was created with the unlaunch .tmd file instead!" and this "Hi, @ThisIsDaAccount, I have found a bug related to European DSi consoles and the tempNand unlaunch installer."
That sounds as if you've used an unofficial installer made by ThisIsDaAccount? The official installer would be "unlaunch.dsi" itself (you might need to rename it to "boot.nds" when starting it via common exploits).
My own installer doesn't contain any functions for creating new directories, so no idea where the 484E4145 (US) folder came from. And, my installer is using "\sys\HWINFO_S.dat" to determine the folder name for your region (from the "PANH" string in that file, with "P" being europe). My understanding is that the original firmware/bootcode is doing it the same way, so my installer should use the correct folder for your region.
Downgrading from 1.4.5E to 1.4E should be no problem (I've done that myself, for using sudokuhax). I can't imagine a situation where unlaunch installer can't find the correct .tmd file whilst the console's bootcode can still find it & boot up successfully. More likely, you could end up in a situation where both can't find the .tmd file (=console is bricked because you got something wrong when downgrading).
if Europe is "HNAP" then America must be "HNAE".
Code:
$ python3
>>> b"HNAE".hex()
'484e4145'
nocash wrote:
satelman wrote:
I can install any version of unlaunch (I tried 0.8, 0.9 and 1.3 so far) and all these versions seem to install fine, however, they do nothing.
Reminds me about this:
https://gbatemp.net/threads/my-nintendo ... -8.516016/That ended up with the person saying to know what was wrong, whatever that was (myself, I've no idea what was wrong).
Oh, and you've posted this here
https://gbatemp.net/threads/unlaunch-ds ... st-8298477 saying "not changed at all in the 484e4150 (EUR) folder, but a new folder, 484E4145 (US), was created with the unlaunch .tmd file instead!" and this "Hi, @ThisIsDaAccount, I have found a bug related to European DSi consoles and the tempNand unlaunch installer."
That sounds as if you've used an unofficial installer made by ThisIsDaAccount? The official installer would be "unlaunch.dsi" itself (you might need to rename it to "boot.nds" when starting it via common exploits).
My own installer doesn't contain any functions for creating new directories, so no idea where the 484E4145 (US) folder came from. And, my installer is using "\sys\HWINFO_S.dat" to determine the folder name for your region (from the "PANH" string in that file, with "P" being europe). My understanding is that the original firmware/bootcode is doing it the same way, so my installer should use the correct folder for your region.
Downgrading from 1.4.5E to 1.4E should be no problem (I've done that myself, for using sudokuhax). I can't imagine a situation where unlaunch installer can't find the correct .tmd file whilst the console's bootcode can still find it & boot up successfully. More likely, you could end up in a situation where both can't find the .tmd file (=console is bricked because you got something wrong when downgrading).
I posted in several places and tried different approaches because I was a bit desperate with my situation: I downgraded my DSi from 1.4.5 to 1.4 and created this downgraded nand copy ONLY AFTER installing unlaunch --when I should have created a clean nand before doing anything else, my mistake. The resulting downgraded nand worked fine, had no unlaunch installed, but strangely enough, whenever I tried to install unlaunch again, the installer said that everything went OK, but all I got was the original DSi home menu without the exploit. And I couldn't understand why unlaunch refused to properly install.
My intention was to have a 'clean' downgraded 1.4 nand without unlaunch but with the possibilty of installing it again in the future if I wanted to. After some more testing and different working nands (previously tested in NO$GBA), I found a 'strange' solution: if I set the original .app and .tmd files in the nand launcher directory as read-only, then this resulting nand allows you to install unlaunch as usual again! Why is this happening? What does protecting the original files against writing do to make this possible? I thought that the unlaunch-modified .tmd had to be write-protected in order to work properly, but... the original files?? Can you explain this?
Apart from that, I also tried another different approach, and I injected the unlaunch.dsi installer directly into a nand copy through the latest tempNand tool, but this is a different story altogether, and the new issue I found in this case is related to the way tempNand works, not to your installer (also, I tried this after writing my first post to you). Basically, the author of tempNand added this unlaunch feature to his tool having US consoles in mind only, and so tempNand puts the unlaunch-modified .tmd into the wrong place when creating a European nand (it uses the US ...45 folder, instead of the ...50 European folder). I wanted him to know, so that he may check this behaviour and fix it in a future update of tempNand in case he wants to include support for other regions.
As you can see, there are two different issues here, one related to your installer on the one hand, and another related to ThisIsDaAccount's installer on the other hand.
So, to sum up, do you have any ideas why setting a downgraded nand .app and .tmd files in the 00030017\484e4150\content folder as read-only allows installing unlaunch, but leaving them without the read-only attribute does not? This still puzzles me.
satelman wrote:
So, to sum up, do you have any ideas why setting a downgraded nand .app and .tmd files in the 00030017\484e4150\content folder as read-only allows installing unlaunch, but leaving them without the read-only attribute does not? This still puzzles me.
No good ideas... but some random bad ideas...
Are you doing something totally unexpected, like installing unlaunch, and then running your emmc image through a batch file that overwrites the modified .tmd file by the downgraded 1.4E files? Or have some special bootcode.dsi file on your SD card that is intentionally overwriting the .tmd file?
The read-only attribute should have no effect on the unlaunch installer, unless the tool that you are using to change the attribute is also manipulating further bytes in the directory; one idea would be that it might delete the old directory entry and create a new entry - in a different directory sector or even a different cluster (if that should happen then it should still work, but it isn't really tested as most DSi directories are smaller than 200h bytes, and thus occupy only a single sector).
When using the "Install Now" function unlaunch.dsi, you should see about 10 messages with green font showing the installation progress, and then an orange message saying "Installation complete" - are you seeing that?
If yes, eject your SD card, and then power off/on. You should then see the unlaunch boot screen, followed by the launcher system menu screen.
PS. Are you doing the installation on real hardware, or in no$gba?
Hello, I just recently updated to Unlaunch 1.5 for hiyaCFW (on a native 1.4U console) and I only came upon 1 problem. SysNAND's touch functionality works on the system menu but once I use emuNAND(hiyaCFW), touch functionality stops working on the system menu. Other applications seems to fine, but it's only just the SDNAND that's having problems with the touch functionality.
Updated to 1.5, and finally it no longer freezes
! As for the touch issue some people are having, o me the touch didn't work only once. I also tried the card boot, and i can confirm now games with wifi support boots, except for my copy Pokemon White, that remains stuck on a black screen (worth noting this a TWL card, and all teh other i have are NTR).
ChampionLeake wrote:
Hello, I just recently updated to Unlaunch 1.5 for hiyaCFW (on a native 1.4U console) and I only came upon 1 problem. SysNAND's touch functionality works on the system menu but once I use emuNAND(hiyaCFW), touch functionality stops working on the system menu.
Good that you found that bug so quickly, thanks! I've uploaded v1.5 just a few hours ago (and didn't even announce it anywhere yet). Ah, yes, I'm gettiing the same problem when booting DSi System Flaw cartridge. Hmmmm, the problem is related to these new/additional TSC writes:
Code:
switch to TSC bank 00h
TSC[0:25h]=00h ;DAC Flag Register (00h) (R)
TSC[0:26h]=00h ;DAC Flag Register (00h) (R)
TSC[0:27h]=00h ;Overflow Flags (00h) (R)
TSC[0:36h]=03h ;SDIN (IN Pin) Control (02h or 03h)
TSC[0:75h]=2Ch ;VOL/MICDET-Pin Gain (xxh) (R)
switch to TSC bank 01h
TSC[1:20h]=D4h ;..already? Class-D Speaker Amplifier
TSC[1:2Ah]=14h ;..already? SPL Driver (Left Speaker)
TSC[1:2Bh]=14h ;..already? SPL Driver (Right Speaker)
TSC[1:32h]=61h ;Input CM Settings
switch to TSC bank 03h
TSC[3:02h]=98h ;SAR ADC Control 1 (00h)
TSC[3:03h]=87h ;SAR ADC Control 2 (00h)
TSC[3:04h]=22h ;Precharge and Sense (00h)
TSC[3:05h]=04h ;Panel Voltage Stabilization (00h)
TSC[3:0Eh]=ADh ;Reserved / Undocumented (read by DSi for Pen Down Test) (0Fh)
TSC[3:0Fh]=A0h ;Scan Mode Timer (40h)
TSC[3:10h]=88h ;Scan Mode Timer Clock (81h)
switch to TSC bank 00h (as default state)
That new writes were supposed to have the TSC registers in exact same state as how the launcher is initializing them, or at least in the state how launcher ends up when being emulated in no$gba, which apparently isn't working perfectly correct on that stuff.
Okay, I've uploaded another update,
unlaunch v1.6, that's having those TSC writes removed again. Half of them were nonsense anyways as they were writing to read-only bits; and at least one of the write-able bits must have caused the problem.
The reason for having that stuff (and half a dozen other changes) in v1.5 was trying to get DSi Sound working, the changes didn't really help on that issue, but I had hoped that they would improve some details in other situations, without screwing up things.
DSi Sound itself didn't work because that specific title is actually requiring Main RAM to be zerofilled. So I am now doing that zerofilling for best compatibility, although it's slowing down the boot process and not needed for most other titles. The good thing is that I found out that zerofilling can be made a bit faster when using the new NDMA fill-mode:
Code:
;benchmarks for filling 0ff8000h bytes (15.9MB) Main RAM with all program code residing in VRAM
;263ms via NDMA3 on ARM7 when SRC=FILLWORD in NDMA.FILLDATA ;<-- best
;265ms via NDMA3 on ARM9 when SRC=FILLWORD in NDMA.FILLDATA
;344ms via STMIA in VRAM code on ARM7 by software zerofill
;369ms via STMIA in VRAM code on ARM9 by software zerofill (with parts of main ram having write-cache)
;393ms via NDMA3 on ARM7 when SRC=FILLWORD in ARM7.WRAM
;393ms via DMA3 on ARM7 by hardware zerofill
;393ms via DMA3 on ARM9 by hardware zerofill
Last month my best result was about 400ms, which is now down to 263ms for DSi titles (and 66ms for NDS titles with only 4MB memory used). And, to speed up homebrew booting, I've added an 16byte ID string in the cart header that allows to disable the zerofilling for faster booting:
Code:
carthdr[0B0h]="DoNotZeroFillMem"
Well, customizing the carthdr isn't optimal, but that was the best solution I could think of. Now that I've that feature... I will probably change it to also affect ITCM/WRAM zerofilling in future - that is, destroying that memory (including the BIOS AES keys) if the ID string isn't present.
If your bootcode.dsi file does require those AES keys: Best add the above ID string right now to avoid future issues.
edo9300 wrote:
Updated to 1.5, and finally it no longer freezes
I've no idea what has fixed that issue, but if it's working stable now then it's just fine. Oh, I just noticed that I've disabled a few more changes (apart from the TSC writes) in v1.6. So maybe I've thrown you back to freezing state with that newly removed changes. Please let me know if v1.6 is still working for you. If it isn't then that does at least help to track down what was causing the problem : )
Alright, and here are the URLs and release notes for the updates...
http://problemkaputt.de/unlaunch.htm - unlaunch
http://problemkaputt.de/gba.htm - no$gba
http://problemkaputt.de/wifiboot.zip - wifiboot
Code:
v1.6 30 Sep 2018
- re-fixed dsi touchscreen input
v1.5 30 Sep 2018
- co-releases: no$gba v2.9b and wifiboot v2.3
- zerofill main ram support added (needed for a few titles like DSi Sound)
- zerofill done via fast NDMA-fill (16MbyteDSiMode=263ms, 4MbyteNdsMode=66ms)
- zerofill skipped if carthdr[0B0h]="DoNotZeroFillMem" (fastboot for homebrew)
- memory moved exploit entry code to gap between 37F0E3Ch and 37F22C8h
- memory shares cluster_buf as rom_cart_xxx buffers (for sd/mmc vs rom carts)
- moved wifi firmware load prior to cartload (so wifi can trash main ram)
- added warnings on unsupported cluster sizes (too small or too large)
- allows FFFFh as 'valid' camera id (for consoles with broken camera/cables)
- speedup: uses DMA for modcrypt (some dsiwares have HUGE modcrypt regions)
- added warning on unknown chinese firmware & unknown old firmwares from 2008
- added uninstall function (dealloc clusters, change filesize, unprotect)
- added warning about uninstall function (prompt X+Y buttons to confirm)
- initializes microphone MIC_CNT, teak DSP_xxx, stop/clear NDMA before title
- vram_code (moved unlaunch to vram; faster & leaves main ram to loaded title)
- gif: much faster gif decoder (r0-r12 instead ram, faster code table)
- gif: simplified gif decoder (no interlace, without wrap at image width)
- gif: special edition themed on broken arrow cold war nuclear accidents
- added support for modcrypt with more than FFFFh blocks (eg. dsi sound)
Code:
30 Sep 2018 - version 2.9b
- web: created no$project patreon page, https://www.patreon.com/martin_korth
- dsi/emu: allows 8bit vram writes on dsi (if enabled in SCFG_EXT9.bit13)
- dsi/help: added note on dsi debug blowfish key used when SCFG_OP nonzero
- carthdr/help: added carthdr[0B0h] "DoNotZeroFillMem"=unlaunch fastboot ID
- dma/help: added note on dma-fill via 40000Exh being slower than stmia/ndma
- dsi/help: added note on broken cameras being more common than unknown cameras
- dsi/tsc/iomap: shows tsc page 0,1,3 registers (page 3 is hidden in aes tab)
- dsi/tsc/emu: basic emulation for reading/writing tsc page 0,1,3 registers
- dsi/startdirect: initializes GPIO registers (sound,powerbutt,wifimode)
- a22i: throws error message on forward references within .pack blocks
- nds/cart: supports flashcarts with arm9 code below offset 4000h (ievolution)
- nds/bugfix: resurrected BG0CNT/BG1CNT.bit13 (unlike GBA) (thanks chocoreep)
- dsi/help: info about ST NAND02G AH0LZC5 emmc chips (thanks barawer+trade girl)
- dsi/emmc: emulates different eMMC CSD's (matched to four known eMMC CID's)
Code:
wifiboot v2.3 - 30 Sep 2018
- added carthdr[B0h]="DoNotZeroFillMem" for unlaunch/fastboot without zerofill
- forces disabled cache to be MADE EMPTY before starting loaded title
- zerofills vram/oam/palette before starting other titles (takes about 6ms)
PS. Now that I've ended up releasing two unlaunch updates on the same day... I could as well threw in a third update:
Code:
v1.7 30 Sep 2018
- re-enabled some other tweaks (except the one causing touchscreen problems)
- webpage: added notes on the new background GIFs
Please let me know if you find something working in v1.6, but not working in v1.7 (or vice-versa).
The faulty TSC init is removed in both versions. v1.6 did also remove some more new features. And v1.7 does have that new features (hopefully properly initializing RCNT, AES_CNT, CAM_MCNT, SCFG_CLK9, SNDEXCNT, and default P15,0,C1,C0,0 setting for DSi).
I had the initial pubic version of unlaunch installed by twlnf because of the mismatch in FAT copies error and previous fixes were not doable for me at the time, then twlnf installed 0.6, bricked it and haven't fully hardmodded my DSi yet so I am using NO$GBA in it's place to test this.
I try using the install/uninstall feature of 1.7 and I get an unknown emmc CID/CSD error.
In text it is:
Code:
BD XX XX XX XX 32 57 37
31 36 35 4D 00 01 15 00
40 40 96 E9 7F DB F6 DF
01 59 0F 2A 01 26 90 00
80 80 FF 80 00 04 00 00
00 00 00 00 00 00 00 00
00 09 00 00 00 01 D0 40
00 00 01 00
I also attached a screencap of the installer if needed.
Keep doing what you're doing, wish I could donate by patreon or something but I can't at the moment.
updated from 1.4 to 1.7 (haven't tried 1.5 or 1.6), now it never freezes anymore! thanks so much for your hard work!
Kodtiz3D wrote:
I am using NO$GBA in it's place to test this. I try using the install/uninstall feature of 1.7 and I get an unknown emmc CID/CSD error.
Looks like a bug in no$gba, or, wait, are you using an old no$gba version? The latest version is no$gba v2.9b (released just yesterday, alongsides with the unlaunch updates).
The screenshot shows your CID in first 16 bytes (that's the CID that you have in your console, and that you've also stored in the eMMC image in the "no$gba footer"), and the CSD is shown in next 16 bytes (40 40 96 ..), and unlaunch is complaining because the values don't match up with each other (the CID is for an "Newer Samsung" chip, but the CSD is that used in "Older Samsung" chips).
That problem will occur in older no$gba versions, but no$gba v2.9b should compare your CID against all known CIDs (for OldSamsung, NewSamsung, OldST, and NewST chips), and then automatically use the correct/matching CSD for your CID (at least that was supposed to happen, maybe I got something wrong there).
Kodtiz3D wrote:
Keep doing what you're doing, wish I could donate by patreon or something but I can't at the moment.
Thanks, don't worry if you can't donate! Yesterday, nine people have joined the patreon, that's been a really nice surprise and makes my financial situation a good bit less hopeless - thanks everybody!
gabo12 wrote:
updated from 1.4 to 1.7 (haven't tried 1.5 or 1.6), now it never freezes anymore! thanks so much for your hard work!
Good to know. If v1.7 does keep working for edo9300, too, then the freezes are hopefully gone now.
nocash wrote:
Good to know. If v1.7 does keep working for edo9300, too, then the freezes are hopefully gone now.
Tested and have no issues on both 1.6 and 1.7,
Hi nocash, I have a bit of a problem.
I'm on unlaunch 0.6 (installed via twlnf) and have mismatched FAT copies meaning the unlaunch installer doesn't work.
I'm fairly certain that unlaunch 0.6 is one of the versions that bricks due to non-read-only tmd and SRL, this is made worse by the fact I didn't use the official installer, but a twlnf script that manually copied a modified tmd to the NAND.
Is there anything I can do to either safely update unlaunch, or fix my mismatched FAT copies error?
Thanks!
Unlaunch v0.6 could brick the launcher, but loading bootcode.dsi should still work, so it's only semi-bricked and could be still repaired without hardmod (but better avoid that as it would still some extra work).
No, stop! If you've installed it via twlnf then I've no idea if twlnf had write-protected the .tmd and/or .app files, if it didn't then it could give you a full-brick.
For repairing FAT copies: I would dump + decrypt + mount the eMMC, and then run scandisk on it. Then unmount, re-encrypt, and write it back to the console. That's much the same as downgrading via TWLtool, except that you are running scandisk instead of downgrading.
I don't know if scandisk is capable of fixing the problem (ie. if it's using the correct FAT, or if it's using the bad FAT copy, and it might create dozens of (possibly useless) FILEnnnn.CHK files), so better keep a backup before passing your eMMC image through scandisk.
Instead of scandisk, you could also load the decrypted image into a hex editor, and manually copy the 1st FAT to 2nd FAT (1st FAT should be at offset 0010F000h, the FAT size is 6800h bytes, followed by 2nd FAT at offset 00115800h with same size), that should work too, as long as you don't screw it up.
After re-encrypting the repaired image: Best test it in no$gba and check if it can boot into launcher, and start DSiware titles from there.
Before writing the image to the console: Some people have that, but some people say that current tools for doing that aren't perfectly reliable (if it goes wrong then you need a hardmod).
edo9300 wrote:
Tested and have no issues on both 1.6 and 1.7, :)
Fine. Thanks for testing!
I have try a big dsiware on unlaunch 1.7 but still has no sound. it's nintendogs dsiware from china iQue which file is 39MB. I rename it to bootthis.dsi and press X when poweron. but it's still no sound.
Hello!
I have a feature request.
How about having Unlaunch doing something, depending on a flag set in RAM?
For example, if the word "THIS" is written to 0x02000330 by an app (ex. TWiLight Menu++), and then reboots the console, Unlaunch will boot "bootthis.dsi" without the need to hold X.
Would make transitioning into DSiWare in .nds format from TWiLight Menu++ (aka DSiMenu++) much better.
How it works right now, is after the user launches the DSiWare (by renaming to "sd:/bootthis.dsi"), TWiLight Menu++ will tell the user to hold X to boot the DSiWare, and as a result, the console reboots, and into the DSiWare, by X being held.
Also, someone else requested to have Unlaunch start the console NAND by a set flag.
For that, I think having "SKIP" written to 0x02000330, will skip booting any "boot????.dsi" file(s).
Also, would it be possible to have Unlaunch start with white screens, instead of black screens?
Someone from the support Discord server used the uninstaller from the 1.7 installer, and it worked just fine for them. They had a regular sized DSi from launch, I might be able to ask them for more technical info about their DSi if needed.
Finally got around to testing 1.7. Seems to work fine for me. Cart loader still doesn't boot my DS-Xtreme. Had to sell my iEvo, so no longer have that to test so not sure on that one. (my guess is probably still no since you'd need to have the cart in hand to test it. Likely a hardware issue with how the cart responds to commands). Also still can't launch Launcher as bootcode.dsi (even tested it by holding Y to disable Wifi init to let Launcher do this instead, which it seems to get far enough to do that, but still hangs on white screen).
Only reason I can see it still not working is perhaps the different location Launcher expects nand info to be in ram? Would be nice to be able to load Launcher from SD without having to hack together a pre-patched Stage2 built into an SRL.
Hello there,
I installed unlaunch 1.7 using flipnote, following the guide on
https://dsi.cfw.guide/installing-unlaunch and a 4GB SD card. This is an European DSi XL.
With unlaunch installed I can't get to the system menu ("an error has occurred" screen) - it doesn't matter if I hold A or not, or if the SD card is in the DSi or not.
I've tested in no$gba using my nand backup that the same thing happens - the nand backup works, and when I install unlaunch I stop being able to use the system menu. If I set up a bootcode.dsi with the unlaunch installer, I can uninstall it, and then it goes back to normal.
On no$gba I've also tried to use 0.8 and 1.4, with the same results.
The system is on version 1.4.2E.
I am working on making my filesystem functions a bit more flexible. The old functions did manually load folder-by-folder, that worked okay for loading a few relevant files, but it wasn't suitable for loading other files at random locations. Anyways, my new code can now decipher strings like "device:/directory/subdirectory/filename.ext" and then load the specified folders & file. And it's now supporting long filenames (and also keeps supporting short names alternately).
Robz8 wrote:
How about having Unlaunch doing something, depending on a flag set in RAM?
For example, if the word "THIS" is written to 0x02000330 by an app (ex. TWiLight Menu++), and then reboots the console, Unlaunch will boot "bootthis.dsi" without the need to hold X.
Yes, sorts of. Or a bit more flexible: Storing an ID and CRC and the full filename "sdmc:/bootthis.dsi" (or any other "device:/path/name" you might want to use.
I was planning to store that at 2000300h..20003FFh (alternately to the similar "load-this-title-id" stuff stored there by nintendo). Hmmm, but FAT32 allows up about 260 16bit characters (=520 bytes), that are too many bytes to be stored at 2000300h.
Guess I'll store it at 2000800h..2000BFFh, that area should be free for such purposes, and that 1024 byte area would be more than enough for long(est) filenames plus some ID+CRC values.
Robz8 wrote:
Also, someone else requested to have Unlaunch start the console NAND by a set flag. For that, I think having "SKIP" written to 0x02000330, will skip booting any "boot????.dsi" file(s).
Yes, I could probably add that, too. For loading Launcher. And maybe also for loading system settings? Or if the above works, then you could do it manually (though that would require knowing region and version of the launcher/settings files).
Robz8 wrote:
Also, would it be possible to have Unlaunch start with white screens, instead of black screens?
Yes, optionally. I prefer black because wifiboot has black background, but I could store some "favorite bg color" option somewhere in future versions.
Apropos, 2000300h allows to load a specific title-id, right?
There's also something similar at 2000000h (see "BIOS RAM Usage" chapter in gbatek). I am not what that is used for (or if it's used - some titles seem to be testing the title-id in that bytes, but - as far as I can see - without actually doing anything even if the title-id is there). Maybe 2000000h can contain some sort of command line parameters, to be used by the title loaded via 2000300h?
If that's so, then we could maybe adopt that in homebrew, too. Or else store command line parameters elsewhere, like at 2000C00h, or the way how dslink is doing it. Or not at all. In most cases I don't see too much need for command line parameters. Maybe except for browsers or so, where it might be nice to tell the browser to load a specific webpage.
cosarara wrote:
I installed unlaunch 1.7 using flipnote...With unlaunch installed I can't get to the system menu ("an error has occurred" screen)... I can uninstall it, and then it goes back to normal... On no$gba I've also tried to use 0.8 and 1.4, with the same results.... The system is on version 1.4.2E.
Hmmmm, never heard of that issue before. Maybe firmware 1.4.2E is doing some extra error checks not present in 1.4E and 1.4.5E.
wzhy90 wrote:
I have try a big dsiware on unlaunch 1.7 but still has no sound. it's nintendogs dsiware from china iQue which file is 39MB. I rename it to bootthis.dsi and press X when poweron. but it's still no sound.
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.
v1.4.2E should be the "00000004.app" file as found on nintendo's servers. Loading that file into no$gba (via no$gba filemenu, ie. as if it were a ROM-image) does somewhat work (although normally that's working only for real ROM-images, not for DSiware files).
Anyways, it's working okay if unlaunch isn't installed, but throws the error message if unlaunch is installed. Looking closer, the reason is that this launcher version is intentionally or accidentally checking the filesize for it's own tmd file (whilst other older/newer launcher versions are checking the tmd sizes for most or all other tmd files, but not for their own tmd file).
I'll replace the "if size=bad then error" check by "if size=bad then size=208h" so it'll see the default size instead of the size of the patched tmd file. That patch should be compatible with 1.4E, too. And I hope that it won't disturb any other versions.
Btw. did anybody ever dump the earlier firmware versions, and knows if they did even exist? Wikipedia claims that v1.0J didn't exist, and dsibrew says that v1.1J didn't exist, but suggests that there was a pre-installed version older than v1.0J. The available info is quite a mess, and probably inaccurate.
Oh, and unrelated: The v1.4.2E launcher does have the whitelist RSA key in it! So maybe the people claiming that the RSA key was missing ONLY in v1.4 haven't been that wrong at all, except maybe it's missing in v1.4.1, too. The other version do probably have it (unless nintendo was repeatedly adding/removing it).
nocash wrote:
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
unlaunch v1.8 releasedAfter 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 : )
http://problemkaputt.de/unlaunch.htmCode:
unlaunch v1.8 06 Nov 2018
- filesys: decodes lfn's, ascii-case-insensitive, with alternate short names
- filesys: parses path+file strings (eg. sdmc:\dir\subdir\file.ext)
- filesys: skips mount_drive when already having the same device mounted
- directory crawler: scans all folders on eMMC and SD/MMC (xcept DCIM etc)
- directory crawler: creates filelist with all .app/.nds/.dsi files
- directory crawler: adds entries for internal functions cart:, wifi:, sett:
- crawler: doesn't treat volume labels as files (even if named .app/nds/dsi)
- quick crawl: aborts folder reading on 1st UNUSED entry (instead cluster end)
- quick crawl: does NOT load carthdr (instead, done on the fly in filemenu)
- quick crawl: skip data,0003000f,import,progress,shared12,sys,ticket,tmp,dcim
- filemenu: displays all titles from crawler and allows to select/start them
- filemenu: displays carthdr title (instead nintendo's 000000vv.app filenames)
- filemenu: supports scrolling and keyrepeat, loads carthdr's during scrolling
- filemenu: ROM cart eject/insert: auto-updates ROM cart title on the fly
- filemenu: SD/MMC card eject/insert: auto-recreates the whole filelist
- filemenu: displays full filename and pub/prv sizes on lower screen
- filemenu: different colors for card:+wifi:+sett: vs nand: vs sdmc: files
- filemenu: hinge close: auto-power-off
- device list: adjusts savedata names either data\public.sav or filename.pub
- device list: adjusts savedata names either data\private.sav or filename.prv
- autoload: allows retails titles to start titles via 2000300h (via title id)
- autoload: allows frontends to start titles via 2000800h (via path\filename)
- creates title list at 2FFD800h (needed for enter_settings & reboot_title)
- options: allows to configure default boot action and hotkeys A,B,X,Y
- options: shows abbreviated name for each hotkey, and full name for current
- hotkeys not treated as menu-input in filemenu/options (when still held down)
- hotkeys checked early (and multiple times ORed up during boot)
- removed skip wifi-init hotkey (button Y has now other/custum use)
- redirect to "load error" handler when trying to start empty rom/sdmmc slot
- early backdrop init (before decompression) (black, or color from 2000800h)
- patches tmd-size-selfcheck in launcher v1.4.2E (if size=bad, force default)
- patches launcher.carthdr[1B4h].bit3 (needed if loading launcher from sd/mmc)
- patches for launcher applied as usually; when selecting launcher in filemenu
- loads verdata tmd (2FFD7B0h region/filename needed for SysSettings and Shop)
- moved ARM9 "gif_table" to what is "cluster_buf" on ARM7 side
- bugfixed hex32bit_r0_to_string_r1_upcase (was badly bugged on digit 9)
- wifiboot: now included as overlay in unlaunch (allows wifi without SD card)
- added NO ONE IS ILLEGAL tagging, and removed the nuke-crash-bombing pictures
- resumed old GIFs, or actually it's only one of them, for memory reasons
PS. titles
The 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. filenames
There 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 savedata
If the file is in a folder named "CONTENT", then savedata is stored in a
separata "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 be
stored 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 can
use 16bit unicode), however, using such long filenames can quickly exceed the
64 character limit of the DSi's Device List (or it's 8bit character space), as
a workaround, unlaunch is converting the above names to 8.3 character format
before 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 folders
nested (or only three folders with extension alike "MYFOLD~1.EXT", or more than
five folders if folder/filename are shorter than 8 characters).
As shown in the above examples, the longname ("Filpnote Studio (EUR.AUS)") is
same for all three files, but the ~NN suffix may vary for shortnames.
PPPS. autoload
The 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).
Code:
DSi Autoload on Warmboot
------------------------
Overview
Launcher (and unlaunch) can be commanded to autoload a different title.
2000000h Autoload Parameters for newly loaded title ;<-- optional extra
2000300h Autoload via numeric Title ID ;<-- official method
2000800h Autoload via string "device:\path\filename" ;<-- alternate method
2FFD800h Title List (jump-able titles for use at 2000300h)
BPTWL[70h].bit0 Warmboot flag ;<-- required flag
BPTWL[11h].bit0 Trigger reset ;<-- trigger reset
Moreover, autoload can occur on warmboot & coldboot: Launcher autoloads any ROM
cartridge with carthdr[01Fh].Bit2. Unlaunch defaults to autoload any file named
"sdmc:\bootcode.dsi".
Examples
DSi Browser settings screen allows to autoload System Settings (via 2000300h),
and automatically enter the Internet options page (via 2000000h).
Nintendo Zone, if started with Wireless Communications disabled, allows to
reboot itself (via specifying it's own Title ID in 2000300h).
Homebrew frontends for unlaunch could start themselves (via bootcode.dsi) and
then command unlaunch to load another title (via 2000800h or 2000300h).
2000000h - Optional Auto-load parameters (passed on to new title)
2000000h 8 AutoParam Old Title ID (former title) ;carthdr[230h]
2000008h 1 AutoParam Unknown/Unused
2000009h 1 AutoParam Flags (03h=Stuff is used?)
200000Ah 2 AutoParam Old Maker code ;carthdr[010h]
200000Ch 2 AutoParam Unknown (02ECh) ;\counter/length/indices/whatever?
200000Eh 2 AutoParam Unknown (0000h) ;/
2000010h 2 AutoParam CRC16 on [000h..2FFh], initial=FFFFh, [010h]=0000h
2000012h 2 AutoParam Unknown/Unused (000Fh = want Internet Settings?)
2000014h 2ECh AutoParam Unknown... some buffer... string maybe?
Above is the overall skeleton as intended by Nintendo, the purpose/format of
the 2ECh bytes is unknown (there seems to be some relation to entries [0Ch] and
[0Eh], but theoretically, each title could use that bytes as pleased).
2000300h - Nintendo Auto-load feature (via numeric Title ID)
2000300h 4 AutoLoad ID ("TLNC")
2000304h 1 AutoLoad Unknown/unused (usually 01h)
2000305h 1 AutoLoad Length of data at 2000308h (01h..18h,for CRC,18h=norm)
2000306h 2 AutoLoad CRC16 of data at 2000308h (with initial value FFFFh)
2000308h 8 AutoLoad Old Title ID (former title) (can be 0=anonymous)
2000310h 8 AutoLoad New Title ID (new title to be started,0=none/launcher)
2000318h 4 AutoLoad Flags (bit0, 1-3, 4, 5,6,7) ;usually 16bit, once 32bit
200031Ch 4 AutoLoad Unused (but part of checksummed area when CRC len=18h)
2000320h E0h AutoLoad Unused (but zerofilled upon erasing autoload area)
Flags (usually 13h or 17h):
0 IsValid (somehow enables/disables HealthSafety when TitleID is wrong?)
1-3 Boottype (01h=Cartridge, 02h=Landing, 03h=DSiware) (see below)
4 Unknown
5 Unknown
6 LoadCompl (causes some error when set) (loading completed flag?)
7 Unknown
8-15 Unused
16-31 Unused (usually not accessed at all, with normal 16bit reads)
Boottypes (in Flags.bit1-3):
01h = Cartridge (with NewTitleID) (with RSA signed header, or Whitelisted)
02h = Landing ("nand:/tmp/jump.app") (with RSA signed DownloadPlay footer)
03h = DSiware (with NewTitleID) (with RSA signed header)
TitleID.LSW should match DSi cart header (or be reverse of NDS gamecode?)
TitleID.MSW should match DSi cart header (or be zero for NDS titles?)
Note: Many titles do create the above structure even when not requesting to
boot a new file: with NewTitleID=0=none & flags=13h=cartridge (in that case
flags should be ignored, and NewTitleID=0=none has priority).
2000800h - Unlaunch Auto-load feature (via "device:/Path/Filename.ext")
2000800h 12 Unlaunch Auto-load ID ("AutoLoadInfo")
200080Ch 2 Unlaunch Length for CRC16 (fixed, must be 3F0h)
200080Eh 2 Unlaunch CRC16 (across 2000810h..2000BFFh, initial value FFFFh)
2000810h 4 Unlaunch Flags
2000814h 2 Unlaunch Upper screen BG color (0..7FFFh)
2000816h 2 Unlaunch Lower screen BG color (0..7FFFh)
2000818h 20h Unlaunch Reserved (zero)
2000838h 208h Unlaunch Device:/Path/Filename.ext (16bit Unicode,end by 0000h)
2000A40h 1C0h Unlaunch Reserved (zero)
Unlaunch Flags (usually 01h):
0 Load the title at 2000838h
1 Use colors 2000814h (use if loaded title is KNOWN to use such colors)
2-31 Reserved (zero)
The name can use slashes or backslashes for folders, and it can use both long
or short filenames (LFN or 8.3). The total length should not exceed 260
characters including EOL (alike windows MAX_PATH, although WinNT seems to allow
up to 32K characters, which isn't supported here).
"nand:/path/name.ext",0000h File on 1st partition of internal eMMC
"sdmc:/path/name.ext",0000h File on 1st partition of external SD/MMC
"cart:",0000h ROM cartridge (in NDS cartridge slot)
"menu:",0000h Force starting unlaunch filemenu (instead bootcode.dsi)
"sett:",0000h Force starting unlaunch options
"wifi:",0000h Force starting unlaunch wifiboot overlay
Case-sensitivity: device, path and file can use upper/lower case A-Z (not
case-sensititive), however currently any other letters are case-sensitive (eg.
umlaut's or accented letters) (that is, they must be uppercase for short names,
or have matching case for long names).
For black colors, you should also disable backlights before issuing reset (else
screen will flash white for a short moment during initial forced blank; before
unlaunch gets started).
2FFD800h - Title List
Before autoloading a title, one should make sure that the title is actually
installed (and which region code it is having, ie. one should use wildcards
that 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 than
manually crawling the directory tree. However, there are some restrictions: The
Title List contains only titles from the same Maker (as the currently loaded
title), 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 Data
folder (WifiFirmware, Whitelist, VersionData), nor NDS ROM cartridges, nor
anything where Jmp+Mkr flags would be both zero.
If started via 2000300h, then the New Title (from 2000310h) does also receive
the the Old Title ID (from 2000308h) with Jmp flag being set; ie. permitting to
return to the Old Title (to know which title was the old title, one should
probably 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 the
title to reboot itself.
nocash wrote:
unlaunch v1.8 releasedAfter 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 : )
http://problemkaputt.de/unlaunch.htmCode:
unlaunch v1.8 06 Nov 2018
- filesys: decodes lfn's, ascii-case-insensitive, with alternate short names
- filesys: parses path+file strings (eg. sdmc:\dir\subdir\file.ext)
- filesys: skips mount_drive when already having the same device mounted
- directory crawler: scans all folders on eMMC and SD/MMC (xcept DCIM etc)
- directory crawler: creates filelist with all .app/.nds/.dsi files
- directory crawler: adds entries for internal functions cart:, wifi:, sett:
- crawler: doesn't treat volume labels as files (even if named .app/nds/dsi)
- quick crawl: aborts folder reading on 1st UNUSED entry (instead cluster end)
- quick crawl: does NOT load carthdr (instead, done on the fly in filemenu)
- quick crawl: skip data,0003000f,import,progress,shared12,sys,ticket,tmp,dcim
- filemenu: displays all titles from crawler and allows to select/start them
- filemenu: displays carthdr title (instead nintendo's 000000vv.app filenames)
- filemenu: supports scrolling and keyrepeat, loads carthdr's during scrolling
- filemenu: ROM cart eject/insert: auto-updates ROM cart title on the fly
- filemenu: SD/MMC card eject/insert: auto-recreates the whole filelist
- filemenu: displays full filename and pub/prv sizes on lower screen
- filemenu: different colors for card:+wifi:+sett: vs nand: vs sdmc: files
- filemenu: hinge close: auto-power-off
- device list: adjusts savedata names either data\public.sav or filename.pub
- device list: adjusts savedata names either data\private.sav or filename.prv
- autoload: allows retails titles to start titles via 2000300h (via title id)
- autoload: allows frontends to start titles via 2000800h (via path\filename)
- creates title list at 2FFD800h (needed for enter_settings & reboot_title)
- options: allows to configure default boot action and hotkeys A,B,X,Y
- options: shows abbreviated name for each hotkey, and full name for current
- hotkeys not treated as menu-input in filemenu/options (when still held down)
- hotkeys checked early (and multiple times ORed up during boot)
- removed skip wifi-init hotkey (button Y has now other/custum use)
- redirect to "load error" handler when trying to start empty rom/sdmmc slot
- early backdrop init (before decompression) (black, or color from 2000800h)
- patches tmd-size-selfcheck in launcher v1.4.2E (if size=bad, force default)
- patches launcher.carthdr[1B4h].bit3 (needed if loading launcher from sd/mmc)
- patches for launcher applied as usually; when selecting launcher in filemenu
- loads verdata tmd (2FFD7B0h region/filename needed for SysSettings and Shop)
- moved ARM9 "gif_table" to what is "cluster_buf" on ARM7 side
- bugfixed hex32bit_r0_to_string_r1_upcase (was badly bugged on digit 9)
- wifiboot: now included as overlay in unlaunch (allows wifi without SD card)
- added NO ONE IS ILLEGAL tagging, and removed the nuke-crash-bombing pictures
- resumed old GIFs, or actually it's only one of them, for memory reasons
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?
edo9300 wrote:
Tested this new version, and i have to say it's pretty good
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.
Many thanks for the feedback!
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.
Apropos things I never could make sense of:
DLDIAs 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).
EDIT: Made a separate thread for DLDI stuff -
viewtopic.php?f=23&t=18009
Does "Writing a DLDI Driver" at
Chishm's page answer any of your questions?
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.
I have this error when trying to install unlaunch 1.8: "You have discovered unknown old firmware version"
My dsi xl was on 1.4E. I used flipnote to install unlaunch 1.8. I had some problems with hiyacfw and decided to start everything form scratch. So i uninstalled unlaunch using the uninstall option. After that I updated the console to 1.4.5E. Also I deleted 2 brain training games from it's memory. Also the internet browser and nintendo dsi+ internet. Now If i try to install unlaunch again, I get that error.
That is odd. I had added that warning in unlaunch v1.5, hoping to find with people who have old firmware from 2008 (ie. firmware v1.2 or older). Mostly because I want to ask them if they have the same system files as later consoles (eg. font and wifi firmware).
What I am doing is checking the file creation timestamp for the launcher's title.tmd file. If it's saying year 2008 then unlaunch is bugging you with the unknown firmware warning message.
Not sure why you get warning that on firmware v1.4.5E. Maybe your console did originally have v1.2E or older installed? And any later system update(s) did maintain the old file creation timestamp for title.tmd. I don't if that would happen - it would depend on if the update is "overwriting" the old .tmd file, or if it's "replacing" the old .tmd file.
But... you didn't get the warning with firmware v1.4E on the same console? Weird. Or did you use an older unlaunch version back then (ie. something older than unlaunch v1.5)?
EDIT: Stupid question. You said you used v1.8 for install+uninstall (and uninstall didn't even exist before v1.5).
Hmmm, maybe the battery backed realtime clock was somehow reset back to 2008 at time when installing v1.4.5E?
---
Well, I could try to detect older firmware versions via some other method. Best would be checking the version data file (but it's difficult to extract the data from there).
Or better: Does somebody HAVE dumped old firmware versions like v1.0J, and could answer a few questions about it?
Then I could just completely remove the warning about yet unknown firmwares : )
nocash wrote:
That is odd. I had added that warning in unlaunch v1.5, hoping to find with people who have old firmware from 2008 (ie. firmware v1.2 or older). Mostly because I want to ask them if they have the same system files as later consoles (eg. font and wifi firmware).
What I am doing is checking the file creation timestamp for the launcher's title.tmd file. If it's saying year 2008 then unlaunch is bugging you with the unknown firmware warning message.
Not sure why you get warning that on firmware v1.4.5E. Maybe your console did originally have v1.2E or older installed? And any later system update(s) did maintain the old file creation timestamp for title.tmd. I don't if that would happen - it would depend on if the update is "overwriting" the old .tmd file, or if it's "replacing" the old .tmd file.
But... you didn't get the warning with firmware v1.4E on the same console? Weird. Or did you use an older unlaunch version back then (ie. something older than unlaunch v1.5)?
EDIT: Stupid question. You said you used v1.8 for install+uninstall (and uninstall didn't even exist before v1.5).
Hmmm, maybe the battery backed realtime clock was somehow reset back to 2008 at time when installing v1.4.5E?
---
Well, I could try to detect older firmware versions via some other method. Best would be checking the version data file (but it's difficult to extract the data from there).
Or better: Does somebody HAVE dumped old firmware versions like v1.0J, and could answer a few questions about it?
Then I could just completely remove the warning about yet unknown firmwares : )
I've used version 1.8 for install and uninstall. The thing is that i never set the date and the clock. But I've adjusted it now and I get the same error.
PS: Most likely when I updated the console the date was set to 2008.
EDIT: I downgraded the console to 1.4 and then I updated again to 1.4.5E, but this time i set the correct date. Now unlaunch works. But if I choose launcher i have no sound in the menu. This happened before too.
EDIT2: My dsi compatible R4 doesn't start from unlaunch (black screen). It isn't recognized in unlaunch (instead of the name it shows some scrambled tiles). I need to go to launcher and start it from there. My cart: wi-fi R4i v5.0 3ds
www.r4i-sdhc.com
Ok got my DSI back. Tested 1.8 myself now (the reports about HIyaCFW Launcher not working was based on reports I was getting from others so hadn't tested that myself yet).
It's able to boot my prepatched Launcher SRL off SDMC (it just shows up in your file browser with the rest of the apps so didn't have to move it)
It's applying your patches ontop of the existing ones though (so no bootsplash/system menu music). But it otherwise appears to work! But only if I booted it from menu. BUT it seems to take a considerable amount of time. Maybe a full 30+ seconds? If I set it as the default boot option it just blackscreens (waited in excess of a minute to be sure. It never goes any further).
Now if there was a flag I could set in the header to tell Unlaunch to not patch it but still boot it like Launcher then this would replace the need of using a prepatched stage2 SRL. Part of the issue may be due to the existing patches baked into the SRL which may be slowing Unlaunch's loader down. Oh of coarse maybe still good idea to at least patch Launcher so that it doesn't delete it's own TMD (as I recall certain versions of Launcher did this?) in the event someone does boot a custom Launcher that doesn't have SD redirection applied to it.
Oh also I moved it to SD:\\Launcher.dsi and SD:\\Launcher.prv respectively and from the menu it was able to boot it from there too. (but again with Unlaunches patches stacked ontop of the existing patches)
As before it took 30+ seconds to boot. Almost thought it just got stuck. but it did eventually boot it.
EDIT: Tested altering the title ID of Launcher. It would load it immediately after I did this. But Launcher then just white screens. Looks like you can't mess with title ID of Launcher. It doesn't like that. It's not a modcrypt issue. I disabled modcrypt in the header and left it decrypted so I had nothing besides the header CRC to fix after I altered the TID. (that too could be slowing the loader down. It sees that it's launcher and then wastes time trying to decrypt it?)
EDIT2: Re-modcrypted it. This didn't change anything so modcrypt not causing the problem.
Apache Thunder wrote:
EDIT: Tested altering the title ID of Launcher. It would load it immediately after I did this. But Launcher then just white screens. Looks like you can't mess with title ID of Launcher. It doesn't like that.
Then breakpoint on "[2FFE230]?" or whatever you had changed, and patch the launcher code that uses that address.
It's been awhile since I've done any serious hex editing stuff. Don't think I know how to do that anymore.
So I tried launching Pictochat in the Unlaunch menu, and I got the "Communication error" message.
I also tried DS Download Play, and while it seems to be working fine, it doesn't seem to find my DS console that's acting as a server.
Both of these issues also happen when launched via a homebrew launcher on a flashcard, or TWiLight Menu++ (as .nds files).
If you found a fix for those issues, can you show me the fix, so I can implement it to TWiLight Menu++?
Robz8 wrote:
So I tried launching Pictochat in the Unlaunch menu, and I got the "Communication error" message.
Oops, thanks! I've somehow missed noticing that bug. But, yeah, happens here, too.
I haven't tested if it does help, but it might be due missing channel flags in [2FFFCFA]. I don't have that initialized, and DS Download Play is actually reading from there (and Pictochat maybe, too). It should be usually set to 1041h (channel ch1+7+13). No idea if that's valid for all countries though.
nocash wrote:
Robz8 wrote:
So I tried launching Pictochat in the Unlaunch menu, and I got the "Communication error" message.
Oops, thanks! I've somehow missed noticing that bug. But, yeah, happens here, too.
I haven't tested if it does help, but it might be due missing channel flags in [2FFFCFA]. I don't have that initialized, and DS Download Play is actually reading from there (and Pictochat maybe, too). It should be usually set to 1041h (channel ch1+7+13). No idea if that's valid for all countries though.
That worked! Thanks!
Weird that the apps themselves don't set it though...
gorgyrip wrote:
nocash wrote:
That is odd. I had added that warning in unlaunch v1.5, hoping to find with people who have old firmware from 2008 (ie. firmware v1.2 or older). Mostly because I want to ask them if they have the same system files as later consoles (eg. font and wifi firmware).
What I am doing is checking the file creation timestamp for the launcher's title.tmd file. If it's saying year 2008 then unlaunch is bugging you with the unknown firmware warning message.
Not sure why you get warning that on firmware v1.4.5E. Maybe your console did originally have v1.2E or older installed? And any later system update(s) did maintain the old file creation timestamp for title.tmd. I don't if that would happen - it would depend on if the update is "overwriting" the old .tmd file, or if it's "replacing" the old .tmd file.
But... you didn't get the warning with firmware v1.4E on the same console? Weird. Or did you use an older unlaunch version back then (ie. something older than unlaunch v1.5)?
EDIT: Stupid question. You said you used v1.8 for install+uninstall (and uninstall didn't even exist before v1.5).
Hmmm, maybe the battery backed realtime clock was somehow reset back to 2008 at time when installing v1.4.5E?
---
Well, I could try to detect older firmware versions via some other method. Best would be checking the version data file (but it's difficult to extract the data from there).
Or better: Does somebody HAVE dumped old firmware versions like v1.0J, and could answer a few questions about it?
Then I could just completely remove the warning about yet unknown firmwares : )
I've used version 1.8 for install and uninstall. The thing is that i never set the date and the clock. But I've adjusted it now and I get the same error.
PS: Most likely when I updated the console the date was set to 2008.
EDIT: I downgraded the console to 1.4 and then I updated again to 1.4.5E, but this time i set the correct date. Now unlaunch works. But if I choose launcher i have no sound in the menu. This happened before too.
EDIT2: My dsi compatible R4 doesn't start from unlaunch (black screen). It isn't recognized in unlaunch (instead of the name it shows some scrambled tiles). I need to go to launcher and start it from there. My cart: wi-fi R4i v5.0 3ds
http://www.r4i-sdhc.comI think I have exactly the same problem because of wrong dates during that process: I had Unlaunch v1.8 in 1.4, then I uninstalled it, I updated to 1.4.5 and now I cannot install it because of that same error.
How could I downgrade an EUR DSi from 1.4.5E to 1.4? Is there any other way for fixing this and being able to install Unlaunch? Thanks!
Someone is trying to install Unlaunch 1.8, and got the unknown old firmware version error.
Is there any information that should be given?
Note that the user has always been on 1.4.5E.
Me thinks using a database of md5/sha1's of all the known TMD files of the known Launcher versions would have been better for detecting "unknown" firmware versions then using file dates as that could be unreliable. If system does a system update with wrong clock setting, that could easily cause a false flag.
I've recently got the directory tree for firmware v1.0J, interestingly, that firmware did have the file time/date stamps set to year 2000 (instead of 2008), whilst v1.4.5E is apparently often having them set to year 2008 (instead of 2012), so my warning message always fired on the wrong version only : ) but I can remove the warning now.
Some findings for v1.0J:
The whitelist is same as in v1.3U.
The v1.0J font file is same as usually, up to throughout v1.4.5E (same as everywhere else, except korea (and presumably china)).
For whatever reason, the Version Data file does exist twice: A v1.0J file (as expected), and a v0.1A file (apparently some relict from pre-release usa version). I am not sure how (or if) the console is knowing which file to use. The per-region gamecode for the launcher is found in HWINFO_S.dat. But for Version Data, the launcher seems to be just using whichever file it finds in the directory tree (perhaps simply using the folder that occurs first or last in the title directory).
The wifi firmware is 20h bytes smaller as in v1.3U, the only real difference seems to be in part 1.C (the bootstub code for reading the I2C EEPROM data; I haven't disassembled the v1.0J code, but I guess it's some small bugfix, or - the newer code does support EEPROMs with different sizes - maybe the old code did support only one EEPROM size).
The serial/barcode in HWINFO_S.dat starts with letters TJH for japan (probably with some variations on older/newer japanese DSi's, and japanese DSi XL's).
Oh, and unrelated:
Wifiboot is now supporting WPA and WPA2 using DSi-Wifi hardware, with faster transfers than NDS-Wifi.
See
viewtopic.php?f=23&t=18065&start=30#p231672 for details.
I know it's unrelated, but please help me. I have an 1.4E dsi that gives me an error on every app (no, it's not the wifi module that it's damaged). Using a herdmod I have installed unlaunch. In unlaunch all the apps work, only the settings give an error, but only when i go to internet->connection settings and set a new connection. Is there a simple way to edit the menu launcher to ignore the wifi error so that all the apps will work? I'm guessing if the apps work in unlaunch, there must be a way to make them work in the system launcher.
Might be wifi firmware related. The launcher boots up despite of wifi firmware errors - but refuses to start games if that error had occurred.
For DWM-W024 wifi boards you would need the newer wifi firmware revision, 00000002.app. But you should normally have that in v1.4.
If the bug occurred only after installing unlaunch, try uninstalling it, to see if that helps.
Or scandisk the decrypted emmc image, or compare the wifi firmware file against a redownloaded copy from nusdownloader, in case fat corruption had destroyed it.
nocash wrote:
Might be wifi firmware related. The launcher boots up despite of wifi firmware errors - but refuses to start games if that error had occurred.
For DWM-W024 wifi boards you would need the newer wifi firmware revision, 00000002.app. But you should normally have that in v1.4.
If the bug occurred only after installing unlaunch, try uninstalling it, to see if that helps.
Or scandisk the decrypted emmc image, or compare the wifi firmware file against a redownloaded copy from nusdownloader, in case fat corruption had destroyed it.
Thank you. I have updated the wifi with nus, no change. The nand works fine in NO$GBA. Not unlaunch is causing the error. It's hardware related (something between the wifi board and the cpu). In fact, unlaunch saved this board from the trash. I was hoping for a simple solution to edit the launcher to ignore the wifi board.
For a cpu-to-wifi wiring diagram, click the picture at the bottom of the no$gba webpage. But that would be useful only if the problem is a broken wire between cpu and wifi. Bad solderpad underneath of the cpu would be more difficult, and burned transistor inside of the cpu would be even worse. A bit easier would be dirty or worn out pins on the wifi board connector.
Did you try using a different wifi board? And does the wifi itself work, eg. in dsi browser? Well, to test that with nonworking system settings, you would need to configure the access point settings for the wifi board on another console, or rename your access point to use matching ssid and password of an already configured access point, you can dump the access point settings in wifi flash aka "in nds firmware chip" with fwtool.
Hmmmm, and the problem might be yet elsewhere, the main reason that makes you think that it's wifi related is the nonworking system settings stuff, right?
nocash wrote:
Hmmmm, and the problem might be yet elsewhere, the main reason that makes you think that it's wifi related is the nonworking system settings stuff, right?
You are correct. And yes, I've also tested it with different known working wi-fi boards. In the past i even replaced the wifi connector and it didn't help. I think it's the solder under the cpu. If this would be a single situation I'd just gave up, but in the past i had over 10 board with the same problem. I salvaged the cart connector and the rest went to trash (there was no unlaunch back then). Now I have 2 boards with this problem. That's why I hopped for a simple way to disable the wifi check in the system launcher. I didn't know the wifi settings are saved on the wifi board. I will test when I get home.
EDIT: I used a working dsi and set up a wifi connection. I also accepted the user agreement in system settings. I removed the wifi board and placed it in the broken dsi. Now i started the browser from unlaunch. It tells me I must accept the dsi network services agreemnet. Now I go to system settings---internet---user agreement. It tells me it must connect to the internet. And it just searches for the connection. The small icon on the top screen for the signal strength show no lines. So there's no internet connection. The same thing for the shop. In pictochat I get this error: "communication error. the nintendo ds will now shut down.". Also if I shortly press the power button for reset (in doesn't matter in what app) the console resets, but unlaunch doesn't come on, only black screens.
Are the disabled RSA checks supposed to carry over when loading an item from the system menu / launcher? I'm wondering because I experimented with changing the version info (title\0003000F\484E4Cxx\content) and that leads to an error screen when opening some items (System Settings, DSi Shop, and 3DS Transfer Tool). Everything else still opens okay (DSi Sound, games/DSiWare, DS Download Play, DSi Browser, DSi Camera).
This is with unlaunch v1.7.
I tried replacing the hash in the TMD assuming that hash checks still occur even if the TMD signature check is bypassed. There's also a signature before the NitroARC section in the .app file, but I hoped that would be bypassed as well.
I also tried leaving the TMD alone in case the TMD signature is checked but not the hashes. However, that would still leave the signature before the NitroARC data as invalid.
Any help would be very welcome. Thanks!
System Settings and some other system apps may have their own checks and those are not patched out. Only Launcher. As I recall with my System Settings, I just modified the Ver string inside the app instead of trying to modify the version data SRL.
Yes, only launcher is patched, things like system settings aren't patched (though you could do so yourself).
Apropos modifying version data, there is this thing in there:
Code:
user_area_size.bin - eg. 08000000h (signed) (=128Mbyte?) (aka 1024 "blocks"?)
It would be interesting if that value does really affect the amount of useable SD/MMC space for DSiware. Did you test that when messing with the file?
nocash wrote:
Yes, only launcher is patched, things like system settings aren't patched (though you could do so yourself).
I guess I'll have to find out if it's practical to do myself. Modifying some data is trivial compared to having the knowledge to properly modify unlaunch and/or DSi code, and sadly the latter may to be out of my reach right now.
I noticed that v1.8 apparently loads the version data based on the release notes. What does unlaunch load it for if the System Menu doesn't normally load and use it?
nocash wrote:
Apropos modifying version data, there is this thing in there:
Code:
user_area_size.bin - eg. 08000000h (signed) (=128Mbyte?) (aka 1024 "blocks"?)
It would be interesting if that value does really affect the amount of useable SD/MMC space for DSiware. Did you test that when messing with the file?
I didn't test that, no. I was only looking at changing eula_url.bin, nup_host.bin, and NintendoCA-G2.der in relation to keeping the DSi highly or fully functional online when (not if) the servers those are dependent on are shut down.
Hello, I am using Unlaunch 1.8 on a normal DSi. the program is refusing to launch a NTR cart(tried 3 games) and the games work from the normal DSi menu. I was told to come here after some people and I on the NDS(i)Brew scene discord. We tried HBChecker and reinstalling all the programs as well and testing different sd cards. Any assistance?
Is that a retail cartridge, or flashcart? Or something with special add-on hardware in it?
And do you mean all 3 games don't work, or only 3 games don't work (and others do work)?
If it's a cheap cartridge, easiest would be if you would donate it... then I could look for myself & fix it.
I've tested booting from rom carts with 6-7 retails carts (mostly NDS carts, and some DSi carts), and those are all working fine. The cart loading is a bit tweaked to make it faster than how nintendo is doing it (which might cause problems if a few games require to be booted more slowly or with smaller sector sizes). And apart from cart hardware/timings, there could be software/initialization issues (then the games may have the problems when starting them in no$gba).
Have the same "you have discovered unknown old firmware version" when try to install unlaunch 1.8 on japanes 1.4.5J. Is there will be new version of unlaunch ?
nocash wrote:
Is that a retail cartridge, or flashcart? Or something with special add-on hardware in it?
And do you mean all 3 games don't work, or only 3 games don't work (and others do work)?
If it's a cheap cartridge, easiest would be if you would donate it... then I could look for myself & fix it.
I've tested booting from rom carts with 6-7 retails carts (mostly NDS carts, and some DSi carts), and those are all working fine. The cart loading is a bit tweaked to make it faster than how nintendo is doing it (which might cause problems if a few games require to be booted more slowly or with smaller sector sizes). And apart from cart hardware/timings, there could be software/initialization issues (then the games may have the problems when starting them in no$gba).
Retail carts. Pokemon soulsilver and pokemon diamond. No games work
Hello, I am using Unlaunch 1.9 on a normal DSi with HiyaCFW. If I try to launch some DSiWares using TwiLightMenu++, I get no sound (for example the DSiWare Maestro Green Groove). I've been told in another forum that this issue is related to unLaunch and not to TwiLightMenu++ as TwiLightMenu++ run DSiWares through UnLaunch. I then installed the game to the EmuNand and:
- if I run the game (Maestro Green Groove) through the DSiMenu I correctly get sound
- If I run the installed game directly through UnLaunch (i.e. I press A+B on DSi Power On and choose the installed game in the unlaunch file list) I get no sound (same behaviour as launching the game through TwiLightMenu++)
And, finally, if I run the .NDS file directly through UnLaunch I get an error (save file missing / damaged) but I think this is expected.
Thanks!
ederenzi78 wrote:
Hello, I am using Unlaunch 1.9 on a normal DSi with HiyaCFW. If I try to launch some DSiWares using TwiLightMenu++, I get no sound (for example the DSiWare Maestro Green Groove). I've been told in another forum that this issue is related to unLaunch and not to TwiLightMenu++ as TwiLightMenu++ run DSiWares through UnLaunch. I then installed the game to the EmuNand and:
- if I run the game (Maestro Green Groove) through the DSiMenu I correctly get sound
- If I run the installed game directly through UnLaunch (i.e. I press A+B on DSi Power On and choose the installed game in the unlaunch file list) I get no sound (same behaviour as launching the game through TwiLightMenu++)
And, finally, if I run the .NDS file directly through UnLaunch I get an error (save file missing / damaged) but I think this is expected.
Are you sure about Unlaunch 1.9? As far as I remember, the latest release yet was Unlaunch 1.8.
Yes, missing sav file could be a problem... if the file file is missing (but you could fix that issue yourself (don't know if that would help on sound issues)).
In general, sound should be for working, for example when loading Flipnote via unlaunch (either from SD or eMMC). Did you test that, too, and does it work for you?
If some titles don't have sound... that might be due to whatever special case. Does the game use Teak DSP sound? New or old TSC mode? And are there any obvious wrong settings... like one of the vatious sound control registers muting sound output? Maybe you could see something eye-catching when runnung SD and eMMC images in no$gba.
CrazyAlexx wrote:
Retail carts. Pokemon soulsilver and pokemon diamond. No games work
Oh, those seem to be quite expensive, and at least one them is said to have special infrared hardware (though I don't know if that's wired to the SPI bus, or to the ROM bus, and if that extra hardware is related to the problem at all).
I am afraid that I've no idea how to fix what without having those games. Only idea would be looking at the cart header of those cartridges (or of the Maestro dsiware title). Can you post a copy of those headers? Only the first kilobyte, not the whole rom-image.
Voodoo wrote:
Have the same "you have discovered unknown old firmware version" when try to install unlaunch 1.8 on japanes 1.4.5J. Is there will be new version of unlaunch ?
Yes, I'll try to get around to release something without that message next days.
There seems to be a weird bug with DSiWare booting via args from homebrew.
Sometimes, the DSiWare doesn't boot, but when a button is held (such as L), chances of the DSiWare not booting, are lowered, and thus, the DSiWare boots.
Do you think it's a bug with the CRC calculation function from the BIOS?
I've heard the BIOS functions aren't good.
The SWI functions in BIOS are a bit slow, but they should be stable. And, especially, they shouldn't freak-out in relation to the L-Button. That sounds more like a feature that is actually behaving different when pressing the button - or some timing problem where the button handling is affecting some unstable timings (or memory caching, or maybe triggering a button-irq, or whatever).
Do you have some idea if the problem is in your own code, or in unlaunch, or in official firmware, or whatever other software you are executing?
What args do you mean? The parameter at 2000000h, or the titleid at 2000300h, or the unlaunch filename at 2000800h... or yet something else?
Btw. somebody mentioned missing sound in some games above, and that you (?) had said that it's problem in unlaunch. Do you know what is wrong there?
nocash wrote:
The SWI functions in BIOS are a bit slow, but they should be stable. And, especially, they shouldn't freak-out in relation to the L-Button. That sounds more like a feature that is actually behaving different when pressing the button - or some timing problem where the button handling is affecting some unstable timings (or memory caching, or maybe triggering a button-irq, or whatever).
Do you have some idea if the problem is in your own code, or in unlaunch, or in official firmware, or whatever other software you are executing?
My code looks fine. Nothing seems wrong.
nocash wrote:
What args do you mean? The parameter at 2000000h, or the titleid at 2000300h, or the unlaunch filename at 2000800h... or yet something else?
I'm referring to the unlaunch filename at 2000800h.
nocash wrote:
Btw. somebody mentioned missing sound in some games above, and that you (?) had said that it's problem in unlaunch. Do you know what is wrong there?
My guess is that the sound disable code for the System Menu is affecting some games as well.
Robz8 wrote:
My code looks fine. Nothing seems wrong.
I'm referring to the unlaunch filename at 2000800h.
Okay, so it's your code, passing parameters to unlaunch. That shouldn't be affect by L button.
And you Draining the write buffer and Cleaning the cache lines before rebooting? Especially if you were writing 2000800h from ARM9 side.
Robz8 wrote:
My guess is that the sound disable code for the System Menu is affecting some games as well.
That is simply forcing the volume in low byte of SOUNDCNT (4000500h) to zero.
But that's done ONLY when using Launcher... and my understanding is that the sound DOES work when using Launcher.
Hmmm, I seem to be actually leaving SOUNDCNT uninitialized in unlaunch, but if it's working with Launcher (with the force volume=00h patch) then that would rule out needing the volume setting. And launcher does to zerofill 40005xxh before starting games, so the games can't rely on needing nonzero values in there.
nocash wrote:
ederenzi78 wrote:
Voodoo wrote:
Have the same "you have discovered unknown old firmware version" when try to install unlaunch 1.8 on japanes 1.4.5J. Is there will be new version of unlaunch ?
Yes, I'll try to get around to release something without that message next days.
I have exactly the same problem. Is there any progress about this (or how to bypass the date checking code)?
Thanks for your efforts!
Released update
http://problemkaputt.de/unlaunch.htmv1.9 - 28 Apr 2019
- wifiboot: supports DSi-wifi SDIO hardware with WPA/WPA2 and faster transfers
- updated unlaunch.htm webpage and how-it-works screen (hotkeys, bootcode.dsi)
- no$gba: fixed wifiboot uploader (without nocashio for wifi) (no$gba v2.9c)
- detects MMC cards in SD/MMC slot (upon failed APP_CMD during idle state)
- initializes 2FFFCFAh wifi channels (for dsdownloadplay and pictochat)
- added lowercase font, hotkeys: removed experimental dpad up/down hotkeys
- displays title from icon/title (if any, instead 12-letter cart header title)
- removed unknown firmware warning (wasn't working, and v1.0J is now known)
- filesys/speedup: uses 1-sector fat cache for faster next cluster look-up
- filemenu: also shows files with .srl extension (in case anybody uses that)
- hotkey config: new options include keep (no change) and none (ignore hotkey)
- forces pub/prv savedata size zero for NDS titles loaded from SD/MMC
nocash wrote:
Released update
http://problemkaputt.de/unlaunch.htm - removed unknown firmware warning (wasn't working, and v1.0J is now known)
I can confirm, that it is working now
Thanks again!
Be reasonable folks, Unlaunch v1.9 deletes the System Settings icon from your real NAND. I'm on v1.4.5E, for anyone wondering.
Better wait for Unlaunch v2.0, I guess...
Trash_Bandatcoot wrote:
Be reasonable folks, Unlaunch v1.9 deletes the System Settings icon from your real NAND. I'm on v1.4.5E, for anyone wondering.
Better wait for Unlaunch v2.0, I guess...
Checked and it is not missing on my system (1.4.5j). Are you sure, that it was Unlaunch v1.9? What actions did you do before you realized that your icon is missing?
Trash_Bandatcoot wrote:
Attachments: File comment: Unlaunch is missing the System Settings as well (besides one on the bottom, which is from my SDNAND)
That looks as if the whole system settings ".app" file is missing on your console. The browser and flipnote seem to be missing, too (if you did have had them installed).
There shouldn't be anything in unlaunch that would be reading (and least writing/destroying/deleting) the missing file (except of course, the filemenu is reading the filename and title string, but that shouldn't be harmful).
I would also assume that the problem was caused by something other than unlaunch. Either by some tool that you have used recently. Or, if it was caused by FAT corruption, then the root of the problem may lay years back, and just didn't trigger issues until now.
You can probably find out more if you dump/decrypt/scandisk the console's emmc memory. Finding out what has happened when & why may be more difficult (unless you can install an intact backup, and then reproduce the problem somehow).
werdy wrote:
Trash_Bandatcoot wrote:
Be reasonable folks, Unlaunch v1.9 deletes the System Settings icon from your real NAND. I'm on v1.4.5E, for anyone wondering.
Better wait for Unlaunch v2.0, I guess...
Checked and it is not missing on my system (1.4.5j). Are you sure, that it was Unlaunch v1.9? What actions did you do before you realized that your icon is missing?
I've got reports that it does not happen on 1.4.5J, but someone else on GBAtemp has the same issue. Before this, it was still there, I'm 100% sure.
I'll dump the NAND later today, and I can always recover using an older version of TWtool- let it be risky.
nocash wrote:
Trash_Bandatcoot wrote:
Attachments: File comment: Unlaunch is missing the System Settings as well (besides one on the bottom, which is from my SDNAND)
That looks as if the whole system settings ".app" file is missing on your console. The browser and flipnote seem to be missing, too (if you did have had them installed).
There shouldn't be anything in unlaunch that would be reading (and least writing/destroying/deleting) the missing file (except of course, the filemenu is reading the filename and title string, but that shouldn't be harmful).
I would also assume that the problem was caused by something other than unlaunch. Either by some tool that you have used recently. Or, if it was caused by FAT corruption, then the root of the problem may lay years back, and just didn't trigger issues until now.
You can probably find out more if you dump/decrypt/scandisk the console's emmc memory. Finding out what has happened when & why may be more difficult (unless you can install an intact backup, and then reproduce the problem somehow).
Yeah, speaking of Flipnote and the DSi Browser, I reset my DSi Shop data, which caused those to get deleted, but that happend a long time ago. My DSi was modded around that time (luckly).
My theory is that something happend to the tmd. The DSi menu checks before starting up every time if the tmd's are correct. If they aren't, these apps will be automatically deleted. However, that's still weird considering Unlaunch never touches the system setting's tmd. I'll ask more people around that have the same issue.
Did you already dump the emmc? The tmd files aren't needed for unlaunch, but, yes, if the launcher deletes app files, that would affect unlaunch. Did you do something like starting a US version of launcher/settings on the EU console? Maybe that would result in deleting non-US file(s).
nocash wrote:
Did you already dump the emmc? The tmd files aren't needed for unlaunch, but, yes, if the launcher deletes app files, that would affect unlaunch. Did you do something like starting a US version of launcher/settings on the EU console? Maybe that would result in deleting non-US file(s).
I did not have any time today and I forgot about it in the meantime. :/ If I don't forget to dump the NAND tomorrow, I'll check the emmc as well.
I'm sorry for being dead for SO LONG, feel free to hit me with a shovel.
Anyway, I took a look at the NAND with fuse-3ds and OSFMount and the entire folder was gone. But I realised something...
A month ago, a cartridge named "SystemUpdater" got found with a bunch of .tad files which can be used on TwlNmenu. What I tried to do is install the System Settings .tad which was the matching one. For whatever reason, it came up with a -2011 (it has to do something with the tickets, they're devsigned I believe). I didn't realise at that point that the System Settings got deleted, and right after installing v1.9, the missing icon catched my eye.
How did I find this out? Another friend of mine tried this on his DSi and he lost Pictochat, also landing on a -2011. That made me realise how it happend.
Sorry for the inconvenience, I was wrong yet again!
When/if 2.0 Unlaunch gets released....please support directories in your file browser. I have like hundreds of SRL files spread out all over my SD card and they ALL appear in the main file selection menu. So it takes me ages to find something I need to boot if I need to use Unlaunch to run it.
The directory view thing could be an optional thing you can enable. So that one doesn't have to use it if they don't have many files on SD. But since I have a bunch of homebrew SRLs and a full SD Nand install (similar to HiyaCFW but I handle the photo partition a little differently) there's just way too much stuff to sift through in Unlaunch's file menu.
Hey @nocash ,
Just want to let you know that many more people are now going to install Unlaunch due to a major new DSi exploit being released.
It's called Memory Pit and it exploits the DSi Camera's pit.bin file.
It works on every DSi, every region. (Edit 6-14-19: yes I regret making this previously false claim, but I made it come true ;p)
https://gbatemp.net/threads/memory-pit- ... ra.539432/
Oh yeah on the subject of Memory Pit, currently Unlaunch can't be started directly from it. Could look into making it get along better with Memory Pit or see if it's an issue with Memory Pit's loader. Hard to say. I haven't seen the code for it yet so I don't really know fully what's going on with that exploit.
zoogie wrote:
... major new DSi exploit being released. It's called Memory Pit and it exploits the DSi Camera's pit.bin file.
It works on every DSi, every region.
https://gbatemp.net/threads/memory-pit- ... ra.539432/Yeah, I've heard about it, Nice thing! Though I am still wondering where that "works on every DSi, every region" stuff comes from... probably somebody has somehow confused "the camera exists in all regions" with "the exploit is tested and working in all regions" and then everybody else somehow adopted that concept?
The original release seems to have no info at all about possibly supported firmware versions & regions. For the regions, it would be interesting if it were working in china (if somebody ever finds a chinese DSi for real). For versions, the current exploit seems to work only on newer firmwares. Hmmm, even if a later version of the exploit should fix that... I am a bit pessimistic about gbatemp users; they will probably happily keep telling everyone that they must update their super-rare-undumped firmware version before using the exploit ; )
Apache Thunder wrote:
When/if 2.0 Unlaunch gets released....please support directories in your file browser. I have like hundreds of SRL files spread out all over my SD card and they ALL appear in the main file selection menu.
Yes, that could be a useful feature. For the official "\title\000300tt\4ggggggg\content\000000vv.app" folder/files it's quite a must-have to keep showing them as if they were "all in one folder". But it might make sense to show other folders separately (yet a little bit of extra work).
Hmmm, then I could even drop the idea about allowing users to manually sort files (by dragging them around, similar as in the Launcher GUI). The problems about that idea were handling added/deleted files, and finding some way to merge the eMMC sort-order with the sort-order of different SD-cards (and, a more basic problem: I don't have programmed a CreateFile function yet, which would be kinda required for storing the sort-order).
nocash wrote:
The original release seems to have no info at all about possibly supported firmware versions & regions. For the regions, it would be interesting if it were working in china (if somebody ever finds a chinese DSi for real). For versions, the current exploit seems to work only on newer firmwares. Hmmm, even if a later version of the exploit should fix that... I am a bit pessimistic about gbatemp users; they will probably happily keep telling everyone that they must update their super-rare-undumped firmware version before using the exploit ; )
Currently that exploit only works on the latest vesion of the camera app, so the systems have to be updated to 1.4.5, it's been tested on all teh major regions (even though on the gbatemp thread or in the discord server there wasn't anyone with an australian console, but that should use the same version of the camera app). It has also been tested on an ique dsi system, but with negative results, as apparently that system, even on the latest fw (that is 1.4.6 for china), is using a different camera app, highly probably because the latest versions had the facebook upload function, and obviously facebook isn't available in china, so it might just be using an old build of the camera app, because the first versions didn't have facebook support. Unfortunately it's highly improbably to even check what version of the app is actually installed on the console, unless the user is willingful to do an hardmod and try to decrypt the nand of that console.
From what I've seen, the exploit can work on all versions. There's only been like 2 or 3 revisions of the camera app for USA/Europe and Japan. With Japan having 3 with the other two regions having 2. The non compatible versions still hang when the exploit is attempted so it likely just needs some offsets changed. (I don't know about the other more exotic regions. I assume this flaw impacts them all since the flaw exists on the "latest" revision and seems to impact older revisions too). Firmware updates on the DSi didn't always change the photo app it seems. So there's only like 2 or 3 versions to worry about. Not including what revisions may have existed for other versions. The flaw seems to impact dev hardware too since dev version of the app hangs on the exploit too. So could maybe make it work on dev hardware too. I still keep my nand/SD nand on 1.4 and that version of Photo app still seems vulnerable to the exploit. But shutterbug has only set up the released payload for the latest revision specifically. I hope he adds support for the older revisions. Some may not want to update their firmwares to latest to use this exploit.
As for directory listing. Yeah DSiWare entries for content inside title folder could still be sorted separately (it would indeed be a pain to try and navigate into each one). Another improvement is to sort DSiWare by category. System apps first or last with normal DSiWare sorted separately.
Also I still think it would be nice if Unlaunch supported booting custom versions of Launcher off SD. Currently it attempts to patch any version of Launcher I try to boot with it and changing Launcher's TID does not correct this because it seems you use a different boot process for Launcher? I used a bootstub attached to the arm9 binary that runs first that updates the header info at 0x02FFE000 and 0x2FFFE00 to ensure Launcher still thinks it's running with the original gamecode/TID and Launcher still hangs. It does boot far enough to init wifi? Because I turned wifi off in settings. Unlaunch seems to turn wifi led on before booting anything and then Launcher turns it back off.(might be a good idea to only init wifi when it's actually needed. I think Launcher normally does this and not stage2). I do know changing the TID was enough to get Unlaunch to not use Launcher patches since the title it appeared as in the file menu changed a bit. (it switched from using a hardcoded title to using the banner's title)
My modified Launcher boots far enough to turn the led off again (since I had turned wifi off in system settings). No error in log files in sys/log folder. I assume Launcher expects some different things in ram compared to DSiWare and you handle Launcher like DSiWare if I change the game code in the TID which is what I had to do to avoid it trying to patch it.
Perhaps make it so it doesn't patch SD versions of Launcher. Though maybe for safety you could do your own version of the HiyaCFW's SD nand patch that redirects all NAND operation to SD. Not sure what would happen if folks ran a vanilla unpatched Launcher off SD accidentally. Unpatched Launcher may try and remove the malformed Unlaunch'ed TMD for NAND Launcher. (unless the read only attribute flags was enough to prevent that?)
Anyways an advanced option to disable patches for versions of Launcher started off SD would be nice. Could be an optional setting in the options menu? I don't like having to use a hacked together SRL with the pre patched Stage2 arm binaries put into it. Well it's nice that Unlaunch still boots that one properly.
Hello,
I've installed the new unlaunch version (1.9, along with HiyaCFW) and I still get the problem reported in a previous post regarding the DSiWare "Maestro Green Groove", i.e.
- I installed the game in the SD NAND
- if I run the game through the DSiMenu I correctly get sound
- If I run the installed game directly through UnLaunch (i.e. I press A+B on DSi Power On and choose the installed game in the unlaunch file list) I get no sound
I don't know if nocash is really interested in this thing. If not, I'll stop posting about it (I thought it could be potentially useful to improve initialization).
Thanks!
Hi I was wondering if it would be possible to add an option to Unlaunch to allow us to toggle on and off the ability to silence the DSI menu music. I personally having many fond memory of using the system would like to be able to the music on my menu.
Nocash, I've made some
modifications to Memory Pit and have had a good bit of success getting it to run on other regions (KOR and CHN) and lower firms (1.4 - 1.4.5 All regions). Update: users now reporting 1.0j, 1.2e, and 1.4j working.
I regards to Unlaunch, an iQue (China) DSi owner has successfully run my Memory Pit fork, but the unlaunch installer says "unknown firmware".
Do you have any instructions on what info is needed from that user to get iQue support for Unlaunch? I suspect he's running 1.4.6 but I'll need to confirm that (will update this post in a little while).
Update: he's running 1.4.6C.The user is on Discord, but I'll try to get him to post here. Or I can relay info to him for you.
So, the latest news, thanks to zoogie we managed to dump the nand (as he already said), i tried to manually isntall unlaunc on it and it seems to work just fine. I also noticed a thing, while in the system menu, the emulator drops some fps, maybe because it has to print chinese fonts? idk. If you need the backup to work with, tell me and i'll upload it somewhere pratical for you to download and send you the link (atm it's hosted on a chinese site).
Edit: I've got another dump of an ique system, this time it contains a dump of the firmware and the bios too, but this too is on 1.4.6c. So no older chinese versions available (this system was before on 1.4.5c)
Good to know that chinese firmware is finally dumped!
I will remove the unknown firmware region message in next update.
ederenzi78 wrote:
I don't know if nocash is really interested in this thing.
See here:
viewtopic.php?f=23&t=17581&p=237323#p237480Apache Thunder wrote:
it seems you use a different boot process for Launcher?
Not really... except, there is some special handling for the JPEG RSA keys, but I guess you don't really need that (or can get the same keys even without the launcher gamecode).
And, of course, the patches are a special launcher-only thing. And you'll need similar patches, too. I guess you already have most of them (and the other patches should be mentioned in unlaunch release notes). Maybe you've missed setting carthdr[1B4h].bit3 for enabling SD access in launcher?
Apache Thunder wrote:
Unlaunch seems to turn wifi led on before booting anything
Hmmm, yes, that happens because SDIO wifi init seems to work only when initializing the BPTWL wifi LED register. I'll try to keep the LED off in next version... I guess there should be another BPTWL setting that enables only SDIO access, without switching the LED on.
Or otherwise I could switch the LED back off after wifi init... maybe I should also switch off further wifi-hardware components, which might save battery power. Hmmm, might be worth testing.. but with the dual-power-supply (battery+charger) it isn't soo easy to insert an ampere meter in the power line.
Apache Thunder wrote:
Could be an optional setting in the options menu?
Not too soon. The long-term plan would be porting the the options screen from my NDS firmware to DSi/unlaunch; so that would support checkboxes and text input and everything for changing user name and enabling patches or even activating healthsafety.
For the people concerned about the missing music & sound effects in patched launcher: If you can make a patch that disables music only, and keeps sound effects enabled then I would make that default in unlaunch.
zoogie wrote:
I've made some
modifications to Memory Pit and have had a good bit of success getting it to run on other regions (KOR and CHN) and lower firms (1.4 - 1.4.5 All regions). Update: users now reporting 1.0j, 1.2e, and 1.4j working.
Cool. Then, that seems to be working for all retail regions/versions now?
I hope the official memory pit will support that, too, or are you modifications already part of the offcial memory pit tool?
Btw. I had a look at the pit.bin file, but I didn't figure out what makes it crash. Is it header size being bigger than 18h, or something else?
Oh, and what is the difference between the camera versions/regions? I guess they do merely need different offsets... if the offsets are only a few hundred bytes apart then it might even be possible to make a "works-for-all" pit.bin (when padding the entrypoint with some hundreds of NOPs). Or are the offsets too different for that?
nocash wrote:
Btw. I had a look at the pit.bin file, but I didn't figure out what makes it crash. Is it header size being bigger than 18h, or something else?
Oh, and what is the difference between the camera versions/regions? I guess they do merely need different offsets... if the offsets are only a few hundred bytes apart then it might even be possible to make a "works-for-all" pit.bin (when padding the entrypoint with some hundreds of NOPs). Or are the offsets too different for that?
I just noticed that in the archive containing the "multi version" pit, there's also source code for the payload, a script to inject it and a briev explanation of the exploit. You might give a look at that, also probably the difference between teh version is just a matter of offsets
nocash wrote:
Cool. Then, that seems to be working for all retail regions/versions now?
Seems so, not a single report of a failed firmware/region combo so far. Even dev units have been reported working.
nocash wrote:
I hope the official memory pit will support that, too, or are you modifications already part of the offcial memory pit tool?
Official enough to make it into the official cfw guide!
https://dsi.cfw.guide/(this guide is also no longer advising people to update to 1.4.5, which I'm very pleased about)
nocash wrote:
Btw. I had a look at the pit.bin file, but I didn't figure out what makes it crash. Is it header size being bigger than 18h, or something else?
Indeed , the increased header size is the initial trigger. When the header is adjusted to be larger than 0x18, the entries section is pushed past the pit.bin's allocated size of 0xBBA0 and overwrites a *pointer to a jump address. This target pointer appears to be less than 0x100 past the end of the pit.bin.
* the pointer is actually about 0x4C below the jump address, but that gap is easily covered by address spraying. My address spray is covering a region of about 8KB (overkill, but whatever).
nocash wrote:
Oh, and what is the difference between the camera versions/regions? I guess they do merely need different offsets... if the offsets are only a few hundred bytes apart then it might even be possible to make a "works-for-all" pit.bin (when padding the entrypoint with some hundreds of NOPs). Or are the offsets too different for that?
Code:
Base wram address of pit.bin + 0
rev0 = 0x022CDC20
rev1 = 0x022CD940
rev2 = 0x0231ECE0
rev3 = 0x0231F000
(addresses seem to be the same across regions)
As you see above, there is indeed a huge address difference between rev1 and rev2. This is too wide a difference to cover with one pit.bin. Two pits isn't bad, though. Flipnote needed 3 different notes and it didn't even cover all regions.
I tried to make a universal pit.bin by making the initial pointer overwrite in the entries section context sensitive, but it seems impossible because the target pointer is always the same distance past the pit.bin buffer in each version. Maybe someone with more experience than I could figure out a trick to make it work, I imagine.
ederenzi78 wrote:
Hello,
I've installed the new unlaunch version (1.9, along with HiyaCFW) and I still get the problem reported in a previous post regarding the DSiWare "Maestro Green Groove", i.e.
- I installed the game in the SD NAND
- if I run the game through the DSiMenu I correctly get sound
- If I run the installed game directly through UnLaunch (i.e. I press A+B on DSi Power On and choose the installed game in the unlaunch file list) I get no sound
I don't know if nocash is really interested in this thing. If not, I'll stop posting about it (I thought it could be potentially useful to improve initialization).
Thanks!
I got the same issue with WarioWare Touched! DL (The one that was made for the 3DS), I i run it from a forwarder on my SD Nand it works fine, but from Unlaunch and Twilight no sound.
Here's a little problem that I and a few others have noticed on 1.9.
You can see the placeholder squares in the image below (top screen). This happens after a hotkey is changed in the options menu.
Hello, i am new to the DSi Scene and was trying to get Unlaunch on my Nintendo DSi XL, when i tried both memory pit and flipnote lenny face methods, when i got to HBMenu, it only reads Unlaunch as "Can't read icon/title!" message, and when i tried to start it up, it froze to a white screen, tried all versions 1.9 to 0.8 with both a 4gb card and a 2gb card, always got that white screen, making me turn off the console, i am using a DSi XL on 1.4.5U version ...
Note that Unlaunch in the only tool that didn't worked so far, as i tried and sucessfuly used FWTool to create a NAND Backup, and trying to boot directly into Unlaunch instead of HBMenu using Lenny Flipnote, gave me the white screen directly, i got no idea what to do, and even the NDS(i) Brew Scene discord server couldn't help me, and they tried a lot to ..
I hope you can help me solve this problem ..
How is unlatch currently saving hotkeys? Because it's happening that some people get wifiboot set as default option with no keys when fresh installing unlaunch (and most of the time they think their console is sort of bricked)
Unlaunch stores it' settings in the Launcher TMD that it's code also resides in. This file is on NAND so issues with SD card/missing SD card won't impact it's ability to store settings.
Hi, I was pointed to this thread from RocketRobz on github.
On my DSi XL with Unlaunch 1.9 I have two games that when launched via TWLMenu++ just go to a white screen and then freeze.
These games are Zenonia and Petit Computer.
I just tried downgrading to 1.8 and Zenonia works now. Petit Computer still freezes. These issues appeared after I upgraded from Unlaunch 1.2 to 1.9 after not using my DSi for a while.
Launching from the DSi's stock launcher presents no issues at all.
A Chinese NAND has been found and does not work at the moment with Unlaunch.
Dunno if Korean NANDs work with v1.9 yet, I haven't tested it, but I have a Korean NAND somewhere.
For those wondering, this is v1.4C_dev (dev and retail have such little changes that it works nontheless). Let me know if anyone needs the NAND to add iQue compatibility in a later update.
Released unlaunch v2.0 -
http://problemkaputt.de/unlaunch.htmv2.0 27 Aug 2019
- extra ipc sync before arm9 vram remapping (avoid memory pit arm7 vram crash)
- cosmetic: Wifi-LED kept switched OFF during/after wifi-firmware init
- bugfixes: initializes dsi_flag AFTER vramcnt, and fixed options glitch
- removed warning on unknown chinese region (no longer unknown)
- wifiboot: faster reconnect on warmboot, rtc set, icon/title
I haven't yet tested if it's now working with Memory Pit exploit. Could somebody check that?
The thing that didn't work was that Memory Pit did still execute ARM7 code in VRAM while already having started the ARM9 unlaunch entrypoint, and crashed when unlaunch started to remap & initialize VRAM. Normally that shouldn't happen with NDS/DSi bootloaders. The official bootloader works as so:
- Do the overall booting and set IPC Sync to nonzero values.
- Relocate and execute final 200h-byte bootstubs at 23FEE00h (ARM9) and 380F600h (ARM7).
- Wait until both CPUs set IPC Sync to zero, and, immediately thereafter, jump to the entrypoints
EDIT: Uhm, looks as if I got that wrong, and memory pit wasn't executing anything in VRAM, or at not least not at time when starting the unlaunch entrypoint(s).
Tested it by booting directly from Memory Pit. Stops on Green Screen so never boots it. Not using the initial release build made by Shutterbug though. I'm using the version compatible with 1.4's Camera app. So at least on that version anyways it doesn't work. I've been able to run it from hbmenu that was booted from Memory Pit though. Memory Pit's loader needs some fine tuning. I recall having to use an older build of hbmenu to get Memory Pit to work. At least the unofficial one for 1.4. Don't know if this was an issue for the one Shutterbug made. You could probably just roll your own Memory Pit payload. Probably a better idea instead of trying to deal with what ever flavor of Memory Pit the end user might have.
Oh one bug but not a big deal. Unlaunch won't boot from hbmenu if I don't have Unlaunch.dsi (renamed to NDS file for hbmenu though) at SD card root. I tried to launch it from a sub directory and it hung on white top screen black bottom screen.
Oh and I noticed you were doing some 3DS dev work? You finally have a 3DS? That's cool. Hopefully Unlaunch will have some kind of functionality on 3DS eventually. 3DS like the DSi has a 40 title limit for DSiWare and being able to boot them from SD would be beneficial for 3DS users so even if it won't boot DSi System Menu on 3DS. 3DS also has smaller TWLN partition then DSi NAND so you can't fit as much DSiWare on a 3DS as a DSi either.
It would still be useful for launching carts and DSiWare from SD. That widescreen patch thing they got going on is neat to. I'd like to see them getting that working on DSiWare at some point. Maybe you can help them with that once you get something running on 3DS.
nocash wrote:
I haven't yet tested if it's now working with Memory Pit exploit. Could somebody check that?
The thing that didn't work was that Memory Pit did still execute ARM7 code in VRAM while already having started the ARM9 unlaunch entrypoint, and crashed when unlaunch started to remap & initialize VRAM. Normally that shouldn't happen with NDS/DSi bootloaders. The official bootloader works as so:
- Do the overall booting and set IPC Sync to nonzero values.
- Relocate and execute final 200h-byte bootstubs at 23FEE00h (ARM9) and 380F600h (ARM7).
- Wait until both CPUs set IPC Sync to zero, and, immediately thereafter, jump to the entrypoints
Nice, I'll test asap. There's still no hope for those with the messed up fat tables? You could make a separate tool (or integrate it in unlaunch) that copies the 1st fast table to the address of the 2nd, as that's the wrong one when using twlnf
Having an issue with wifiboot since upgrading Unlaunch to v2.0. A very simple homebrew thing I was working on yesterday (which simply shows some text on the screen) suddenly is unable to start any more, resulting in a plain white screen as soon as the ROM transfer completes. It was working perfectly fine yesterday when I was using v1.9, and has only started occurring since v2.0. I haven't made any changes to the code or re-compiled it or anything between testing it yesterday evening and writing this post, the only thing that's changed is Unlaunch.
Apache Thunder wrote:
Tested it by booting directly from Memory Pit. Stops on Green Screen so never boots it.
I should have tested that myself before releasing the update, and my theory about the vram code problem seems to have been nonsense anyways. Okay, I gave it another look, this time looking at the I/O map windows in no$gba. Memory pit is starting unlaunch with some unusual settings:
Code:
arm9 starts with code cache and data cache enabled
arm7 starts with CPSR irq/fiq enabled
arm7 has value 0004000C in IPC send fifo (this causes green screen crash)
arm7 has sound capture 0 and 1 enabled/busy (this causes below no$gba issues)
unlaunch in no$gba runs super slow even with arm7/halt
unlaunch in no$gba completely hangs in 80x86 emulated ARM7 SWI wait_by_loop
The first two are not so good, but don't seem to cause problems in this case. The non-empty IPC fifo appears to be the cause of the problem; I can get unlaunch booted from memory pit when clearing the IPC fifo (done shortly after the initial IPC sync, so I hope that it won't break other bootloaders).
And the sound capture: It's done with sound capture frequency set to zero, and with sound unit disabled. I am not sure what happens on real hardware in that situation? The sound unit disable might act as master disable, so the capture hopefully won't overwrite main ram. And the frequency setting and emulation slowdown... no$gba is currently excpecting one whole capture block to complete within 0 clock cycles (whatever real hardware is doing,
that current emulation is obviously wrong).
Apache Thunder wrote:
Oh one bug but not a big deal. Unlaunch won't boot from hbmenu if I don't have Unlaunch.dsi (renamed to NDS file for hbmenu though) at SD card root. I tried to launch it from a sub directory and it hung on white top screen black bottom screen.
I've no idea what happens there, unlaunch doesn't know & doesn't care which folder it is booted from (or if it's booted from wifi or other sources).
Apache Thunder wrote:
Oh and I noticed you were doing some 3DS dev work? You finally have a 3DS?
Yes/no, I still need a 3DS console, or a New3DS XL mainboard with intact top-screen connector. At the moment, I can use only the bottom screen... which is good enough for displaying test results, except that the viewing angle isn't so good for reading the test results : /
edo9300 wrote:
There's still no hope for those with the messed up fat tables? You could make a separate tool (or integrate it in unlaunch) that copies the 1st fast table to the address of the 2nd, as that's the wrong one when using twlnf
Is that verified with tools like scandisk? Ie. running scandisk leaves the 1st fat unchanged and updates only the 2nd fat? Or, manually copying 1st fat to 2nd fat does fully repair all errors, so that scandisk will then treat the mmc image as fully intact?
Just overwriting one fat by another is very easy... but I am not so sure if that is a good solution, in worst case it might overwrite the good fat by the wrong fat, or overwrite a fully intact fat by garbage in case of fat-type misdetection. In so far, it might be safer to repair the problem with dedicated tools like scandisk; and as a side-effect, that does force people to make a mmc backup.
But yeah, with some bug testing and error checking it should no problem to repair fats directly on the dsi. I am not so motivated to do that stuff because my fat isn't corrupted, and I have a working backup anyways : )
DaPorkchop_ wrote:
Having an issue with wifiboot since upgrading Unlaunch to v2.0. A very simple homebrew thing I was working on yesterday (which simply shows some text on the screen) suddenly is unable to start any more, resulting in a plain white screen as soon as the ROM transfer completes.
Thanks for the feedback! I really didn't knew that anybody had ever used wifiboot. As a quick workaround, so that you can keep working: you could install unlaunch v1.9. Or if you want to investigate what went wrong in which wifiboot version, you could try loading the last some wifiboot versions from SD card, the last three versions are online at
http://problemkaputt.de/wifibo25.zip - this should be (almost) same as in unlaunch v1.9
http://problemkaputt.de/wifibo26.zip - this was released between unlaunch v1.9 and v2.0
http://problemkaputt.de/wifibo27.zip - same as in unlaunch v2.0
The major changes in that versions are added 3DS support (and some support for real time clock and icon/title), theoretically that changes shouldn't affect nds/dsi functionality... unless the problem is related to timings or unitializied memory.
What transfer tool are you using - the no$gba/utility function or devkitpro/dslink tool?
Can you upload the non-working nds file somewhere?
Oh, and are you using Open/WEP/WPA/WPA2?