It is currently Tue Oct 16, 2018 9:17 am

All times are UTC - 7 hours

Post new topic Reply to topic  [ 101 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7
Author Message
PostPosted: Sun Sep 30, 2018 2:01 pm 

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

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... - unlaunch - no$gba - wifiboot

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)

30 Sep 2018 - version 2.9b
- web: created no$project patreon page,
- 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)

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)

PostPosted: Sun Sep 30, 2018 2:56 pm 

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 649
PS. Now that I've ended up releasing two unlaunch updates on the same day... I could as well threw in a third update:
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).

PostPosted: Sun Sep 30, 2018 9:19 pm 

Joined: Sun Sep 30, 2018 8:52 pm
Posts: 2
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:
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.

unknown emmc.PNG
unknown emmc.PNG [ 104.86 KiB | Viewed 479 times ]
PostPosted: Mon Oct 01, 2018 5:21 am 

Joined: Sat Aug 18, 2018 7:47 am
Posts: 3
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!

PostPosted: Mon Oct 01, 2018 12:26 pm 

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

PostPosted: Mon Oct 01, 2018 12:51 pm 

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

PostPosted: Mon Oct 01, 2018 12:54 pm 

Joined: Mon Oct 01, 2018 12:50 pm
Posts: 1
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?

PostPosted: Mon Oct 01, 2018 1:36 pm 

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

PostPosted: Tue Oct 02, 2018 2:52 am 

Joined: Sun Sep 02, 2018 6:44 am
Posts: 2
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.

PostPosted: Tue Oct 02, 2018 4:10 pm 

Joined: Sun Aug 05, 2018 12:52 pm
Posts: 4
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?

PostPosted: Sun Oct 07, 2018 7:25 pm 

Joined: Sun Sep 30, 2018 8:52 pm
Posts: 2
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.

Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 101 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7

All times are UTC - 7 hours

Who is online

Users browsing this forum: No registered users and 2 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