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!
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.