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: Select all
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
- this should be (almost) same as in unlaunch v1.9
- this was released between unlaunch v1.9 and v2.0
- 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?