More actions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
| image = https://dlhb.gamebrew.org/3dshomebrew/NTRLDR.jpg|250px | | image = https://dlhb.gamebrew.org/3dshomebrew/NTRLDR.jpg|250px | ||
| type = System Tools | | type = System Tools | ||
| version= | | version=2018 | ||
| lastupdated = 2018/03/07 | | lastupdated = 2018/03/07 | ||
| licence = Mixed | | licence = Mixed | ||
| Line 9: | Line 9: | ||
| website = https://gbatemp.net/threads/release-ntrldr-ds-firmware-on-the-3ds.497852/ | | website = https://gbatemp.net/threads/release-ntrldr-ds-firmware-on-the-3ds.497852/ | ||
| download = https://dlhb.gamebrew.org/3dshomebrew/NTRLDR.rar | | download = https://dlhb.gamebrew.org/3dshomebrew/NTRLDR.rar | ||
| source = | | source = https://github.com/strdr1ft/ntrldr | ||
}} | }} | ||
<youtube>izljcyvozig</youtube> | <youtube>izljcyvozig</youtube> | ||
Hello! | Hello! | ||
I've been very intrigued as to why the old firmware.nds file failed to load properly under the 3DS. After almost a week of research and experimentation, I took my first dive into writing homebrew as a means to solve this problem. It's not particularly useful, but I learned a lot and it's a neat little novelty. | I've been very intrigued as to why the old firmware.nds file failed to load properly under the 3DS. After almost a week of research and experimentation, I took my first dive into writing homebrew as a means to solve this problem. It's not particularly useful, but I learned a lot and it's a neat little novelty. | ||
| Line 19: | Line 20: | ||
I do not recommend running this on an NDS or DSi system. It probably won't hurt anything, but it directly writes to flash/NVRAM (which is dangerous) and there's no real reason to (unless you are using SudokuHax or something). <span style="text-decoration: underline">It will almost certainly brick an iQue NDS. | I do not recommend running this on an NDS or DSi system. It probably won't hurt anything, but it directly writes to flash/NVRAM (which is dangerous) and there's no real reason to (unless you are using SudokuHax or something). <span style="text-decoration: underline">It will almost certainly brick an iQue NDS. | ||
'''YOU CANNOT BOOT NDS CARTRIDGES WITH THIS''' | |||
= | ==Technical details== | ||
==='''NVRAM patching'''=== | |||
'''NVRAM patching''' | |||
The reason that firmware.nds traditionally fails on the 3DS is because for some reason NVRAM reports one of the bits in the flag bytes of user settings as a 1, when the DS firmware expects that bit to be a 0. We can write to NVRAM, but every time NTR mode is restarted this bit becomes a 1 again. As such, all we need to do to allow firmware.nds to boot is to flip that bit and correct the checksums in the user settings just prior to chainloading firmware.nds. | The reason that firmware.nds traditionally fails on the 3DS is because for some reason NVRAM reports one of the bits in the flag bytes of user settings as a 1, when the DS firmware expects that bit to be a 0. We can write to NVRAM, but every time NTR mode is restarted this bit becomes a 1 again. As such, all we need to do to allow firmware.nds to boot is to flip that bit and correct the checksums in the user settings just prior to chainloading firmware.nds. | ||
'''TWL->NTR mode switching''' | ==='''TWL->NTR mode switching'''=== | ||
The NDS firmware does not know how to deal with the extra features provided by TWL mode (obviously). The DMA register REG_SCFG_ROM is set to 0x703 to keep the firmware from crashing (this seems to cause the system to disable several TWL features) and writes are made to the TSC to switch it into NDS compatibility mode (see [https://github.com/strdr1ft/ntrldr/blob/master/bootloader/source/boot.c#L414 here]) so that the firmware can understand the touch screen. I found the TSC values by going through [https://github.com/ahezard/nds-bootstrap/blob/f2c30c9aaa03fa0a33a1177fcb62f3eb462ca63e/arm7/source/main.c this code] and trying different combinations of values until I found the right ones. | The NDS firmware does not know how to deal with the extra features provided by TWL mode (obviously). The DMA register REG_SCFG_ROM is set to 0x703 to keep the firmware from crashing (this seems to cause the system to disable several TWL features) and writes are made to the TSC to switch it into NDS compatibility mode (see [https://github.com/strdr1ft/ntrldr/blob/master/bootloader/source/boot.c#L414 here]) so that the firmware can understand the touch screen. I found the TSC values by going through [https://github.com/ahezard/nds-bootstrap/blob/f2c30c9aaa03fa0a33a1177fcb62f3eb462ca63e/arm7/source/main.c this code] and trying different combinations of values until I found the right ones. | ||
I can't supply firmware.nds, but it's not too hard to find if you're interested in trying this. | I can't supply firmware.nds, but it's not too hard to find if you're interested in trying this. | ||
Revision as of 11:08, 17 September 2021
Template:Infobox-3DS-Homebrews
Hello!
I've been very intrigued as to why the old firmware.nds file failed to load properly under the 3DS. After almost a week of research and experimentation, I took my first dive into writing homebrew as a means to solve this problem. It's not particularly useful, but I learned a lot and it's a neat little novelty.
I've tested NTRLDR heavily under an NTR-mode flashcart (CycloDS iEvolution) and under TWL-mode nds-hb-menu (3DS SD). It does not seem to run under TWLoader/nds-bootstrap. firmware.nds is expected to be in the root of the partition /_nds/ntrldr
I do not recommend running this on an NDS or DSi system. It probably won't hurt anything, but it directly writes to flash/NVRAM (which is dangerous) and there's no real reason to (unless you are using SudokuHax or something). It will almost certainly brick an iQue NDS.
YOU CANNOT BOOT NDS CARTRIDGES WITH THIS
Technical details
NVRAM patching
The reason that firmware.nds traditionally fails on the 3DS is because for some reason NVRAM reports one of the bits in the flag bytes of user settings as a 1, when the DS firmware expects that bit to be a 0. We can write to NVRAM, but every time NTR mode is restarted this bit becomes a 1 again. As such, all we need to do to allow firmware.nds to boot is to flip that bit and correct the checksums in the user settings just prior to chainloading firmware.nds.
TWL->NTR mode switching
The NDS firmware does not know how to deal with the extra features provided by TWL mode (obviously). The DMA register REG_SCFG_ROM is set to 0x703 to keep the firmware from crashing (this seems to cause the system to disable several TWL features) and writes are made to the TSC to switch it into NDS compatibility mode (see here) so that the firmware can understand the touch screen. I found the TSC values by going through this code and trying different combinations of values until I found the right ones.
I can't supply firmware.nds, but it's not too hard to find if you're interested in trying this.