It is currently Sun Nov 17, 2019 2:43 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 190 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13
Author Message
PostPosted: Wed Jul 03, 2019 7:28 am 
Offline
User avatar

Joined: Tue Jul 24, 2018 6:28 pm
Posts: 24
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.


Top
 Profile  
 
PostPosted: Wed Jul 03, 2019 11:21 am 
Offline

Joined: Wed Jul 03, 2019 11:15 am
Posts: 1
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.


Top
 Profile  
 
PostPosted: Wed Jul 10, 2019 4:34 am 
Offline

Joined: Fri May 03, 2019 2:38 am
Posts: 7
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.


Attachments:
v1.4c.png
v1.4c.png [ 33.29 KiB | Viewed 5171 times ]
Top
 Profile  
 
PostPosted: Mon Aug 26, 2019 6:06 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1051
Released unlaunch v2.0 - http://problemkaputt.de/unlaunch.htm

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

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Mon Aug 26, 2019 7:48 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1051
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).

_________________
homepage - patreon


Last edited by nocash on Tue Aug 27, 2019 12:52 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 26, 2019 9:29 pm 
Offline
User avatar

Joined: Tue Jul 24, 2018 6:28 pm
Posts: 24
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. :D


Top
 Profile  
 
PostPosted: Tue Aug 27, 2019 3:20 am 
Offline

Joined: Wed Jul 25, 2018 6:34 am
Posts: 33
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


Top
 Profile  
 
PostPosted: Tue Aug 27, 2019 8:24 am 
Offline

Joined: Tue Aug 27, 2019 8:17 am
Posts: 1
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.


Top
 Profile  
 
PostPosted: Tue Aug 27, 2019 7:51 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1051
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?

_________________
homepage - patreon


Top
 Profile  
 
PostPosted: Thu Oct 31, 2019 5:03 pm 
Offline

Joined: Thu Oct 31, 2019 5:00 pm
Posts: 1
When I launch the DSi Camera, it gives me a message saying The System Memory has been damaged. What is causing this error?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 190 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 6 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group