Homebrew [DS(i)/3DS] TWiLight Menu++ - GUI for DS(i) games, and DS(i) Menu replacement

  • Thread starter Thread starter RocketRobz
  • Start date Start date
  • Views Views 5,110,583
  • Replies Replies 17,133
  • Likes Likes 271
0 titles.
"There is no accessible software data." in "System memory" and "microSD Card" sections in "Nintendo DSiWare Management".
Try following the manual steps of TWLMenu++ installation instead of the Universal-Updater steps then.
 
Try following the manual steps of TWLMenu++ installation instead of the Universal-Updater steps then.
I used this instruction for manual installation: https://wiki.ds-homebrew.com/twilightmenu/installing-3ds?tab=manual
Copied only those files that were specified in the instructions (ignored the files snemul.cfg and ntrboot.nds in downloaded archive)
An error was received when trying to install:
Failed to install CIA file
Result code: 0xC9604541
Level: Status (25)
Summary: Internal (11)
Module: FS (17)
Desc: <unknown> (321)
 
Recently I've been getting a red screen crash on my 3DS when playing a new hack of HG called Rainbow Gold by DarthBr. I don't think the crash has to do with the hack necessarily because it works perfectly on MelonDS and R4 cards used on 3DS and NDS systems, however after playing continuously via twlmenu++ for a few hours I get the error code I posted below.

Data abort error code 0201f988 addr: 00000010

Originally I thought it may have been the forwarder I was using or I installed twilightmenu incorrectly, so I did a clean uninstall and reinstall of twilight menu and played directly from twilight menu but the crash still persisted. I was advised to utilize the latest deadskulljr usecheat.dat file, as the hack may call on it, but that didn't seem to work either.

Any ideas on how I might keep the game from crashing? I saw this error code mentioned earlier in this forum so thought this may be a good place to ask here. Thanks in advance!

Some additional info:
The hack was recently updated to work with 3DS, and seems to work in twilight for play sessions shorter than ~4 hours
The hack is provided as a pre patched .NDS file
The device I am using is a CFW N3DSXL with the latest version of Luma
I followed the instructions on the wiki for my install/uninstall processes
 
Last edited by optronix10,
Recently I've been getting a red screen crash on my 3DS when playing a new hack of HG called Rainbow Gold by DarthBr. I don't think the crash has to do with the hack necessarily because it works perfectly on MelonDS and R4 cards used on 3DS and NDS systems, however after playing continuously via twlmenu++ for a few hours I get the error code I posted below.

Data abort error code 0201f988 addr: 00000010

Originally I thought it may have been the forwarder I was using or I installed twilightmenu incorrectly, so I did a clean uninstall and reinstall of twilight menu and played directly from twilight menu but the crash still persisted. I was advised to utilize the latest deadskulljr usecheat.dat file, as the hack may call on it, but that didn't seem to work either.

Any ideas on how I might keep the game from crashing? I saw this error code mentioned earlier in this forum so thought this may be a good place to ask here. Thanks in advance!

Some additional info:
The hack was recently updated to work with 3DS, and seems to work in twilight for play sessions shorter than ~4 hours
The hack is provided as a pre patched .NDS file
The device I am using is a CFW N3DSXL with the latest version of Luma
I followed the instructions on the wiki for my install/uninstall processes
Have you checked if the same crashing issue occurs in the clean unhacked ROM? Because it'd make no sense for the crash to occur after a few hours instead of a few minutes.
 
  • Like
Reactions: optronix10
Hello, I'm having some minor graphical issue in blue rescue team (europe, french version)View attachment 536829View attachment 536830
I HAVE THE SAME ISSUE WHIT BLUE RESCUE TEAM WHEN IM USING NDSBOOTSTRAP BUT WHEN I LOAD THE GAME WHIT YSMENU KERNEL WORK FINE. YOU CAN HAVE TWILIGHT AND YSMENU AT THE SAME TIME AND SWITCH KERNEL WHEN YOU WANT
 
Have you checked if the same crashing issue occurs in the clean unhacked ROM? Because it'd make no sense for the crash to occur after a few hours instead of a few minutes.
First off thank you so much for your reply and all of your contributions to this community!

Based on your previous message I tried to recreate the crash by playing a clean unhacked HeartGold and had the game running for ~8 hours and have not gotten a crash.

Why would it not make sense for it to crash after mins but not hours? Thanks again!
 
First off thank you so much for your reply and all of your contributions to this community!

Based on your previous message I tried to recreate the crash by playing a clean unhacked HeartGold and had the game running for ~8 hours and have not gotten a crash.

Why would it not make sense for it to crash after mins but not hours? Thanks again!
I said it'd not make sense for it to crash after hours.
Crashing after minutes is usually due to an AP measure triggering, but if it's crashing after hours, that'd mean the ROM hack has an obscure bug that only nds-bootstrap triggers (somehow). Have you tried running the ROM hack in DSi mode? That may allow you to run it for more time (like double the hours), making the crash occur later than usual.
 
I said it'd not make sense for it to crash after hours.
Crashing after minutes is usually due to an AP measure triggering, but if it's crashing after hours, that'd mean the ROM hack has an obscure bug that only nds-bootstrap triggers (somehow). Have you tried running the ROM hack in DSi mode? That may allow you to run it for more time (like double the hours), making the crash occur later than usual.
Sorry! I mistyped earlier. I follow what you're saying now.

Just tried running the rom hack in DSi mode and got a crash after an hour or so of playing, so doesn't seem like that helps.

Is it rare for rom hacks to have bugs triggered by nds-bootstrap? Let me know if it would help to provide the ram dumb or pictures of the red screen I get in the crash.
 
Last edited by optronix10,
Hi I own a ezflash parallel and as many people know it doesn't have a sleep function. I noticed while playing Pokemon Black 2 that the c gear state of the game allows the DS to go into a similar mode. Not full sleep but it turns the screens off and turns off the sound. Is there anyway to somehow incorporate that into the menu for people that have my flash card?
 
Quick sanity check —

I’m new to DS internals, but I think I traced RainbowGold’s crash to a NULL dereference near 0201F988 (ldr r0, [r0, #0x10] → Data Abort @ 0x10).

It never crashes for me in melonDS or on an R4, so my current read is that nds-bootstrap’s timing just exposes a missing null-guard in that call path.

You all are way more knowledgeable about this than I am, and I know this isn't really a TWiLight issue, but I wanted to see if someone could verify if l'm at least in the right ballpark with that conclusion.

Happy to share more detail if helpful!
 
Anyone else get a red screen cash for SNK vs Capcom card fighters ds once gameplay / card battling starts ?
 
Anyone else get a red screen cash for SNK vs Capcom card fighters ds once gameplay / card battling starts ?
Assuming this is being run from the SD card slot, are you using a DSi or 3DS?
Also:
  • Do you have a screen color filter (in TWLMenu++ Settings) and/or DS Phat colors (in per-game settings) enabled?
  • Are cheats enabled?
 
Last edited by RocketRobz,
Assuming this is being run from the SD card slot, are you using a DSi or 3DS?
Also:
  • Do you have a screen color filter (in TWLMenu++ Settings) and/or DS Phat colors (in per-game settings) enabled?
  • Are cheats enabled?
No screen filter. No cheats enabled. The game version is (rev 1). Red screen with "Error Data Abort" starts when gameplay with cards begins
 
Tested on my side from the SD card using a DSi, and can reproduce the same issue.
As an attempt to fix the issue, I tried having nds-bootstrap pre-load some ROM data before boot, and it did not fix the issue.
  • Are you using a DSi or a 3DS?
  • Have you used a tool to modify your save file?
I am using a DSi. I have not used a tool to modify my save. I can delete the save and start over though if you suspect that may fix it. I just started the game. Cheers
 
Howdy, I believe I may have found a bug in nds-bootstrap.

I'll go into my setup really quick first. I purchased a 512GB SD card recently to use in my DSi, and I am using most of that space. Putting that much data slowed the DSi down any time it needed to create a new file, such as new save files or patchOffsetCache files. It would fix itself sometimes, if single files were deleted. This lead me down a rabbit hole to explore the theory that the DSi was searching the FAT table of the SD Card from the beginning (ignoring the next free cluster hint) to find free clusters and would take a LOT of time getting through it. I spent some time writing a tool that would move all the files on the card to the END of the available clusters, so that the majority of space at the beginning would be free to allocate new files.

This seemingly has worked, but unfortunately with a catch. The first boot of a game is now really fast, but will fail for some games with "an error has occured", but not for others. I have narrowed down which games it seems to affect. Any games with clusters starting beyond 12980040 will fail, those that go before work fine. The file hashes are correct, so the roms are not corrupted. Copying a rom with godmode9i will make it work fine as well (as it will have moved back to the start of the file system).

GBA games seem to run all fine, even if they are in the "bad zone" where DS games don't work.

While I don't wanna exclude the possibility that me messing with the file system may have broken something, I so far don't have any reason to believe this is the case (I did a filesystem check, and compared some file hashes to be sure). I have run into this particular bug before I was experimenting with editing the FAT32 system directly, only now I seem to have a better idea of what's causing it.

I've attached a screenshot of the filesystem checker utility, which includes some information about my SD's particular filesystem.

dsclusters.png


TL;DR nds-bootstraps fails to load when nds roms start at too large a FAT cluster number (12980040). GBA games still run fine.

Version of nds-bootstrap is v2.9.1

EDIT:
I have tried out launching a couple more games, and it turns out, that some games stored near the end of the card, actually do run. The crash only occurs when the rom is particularly large (so far it seems larger than 56 MB). Large roms early in the file system still work fine however. Perhaps there is a correlation between how big the rom can be before it crashes nds-bootstrap and where it is stored in FAT. This seems tricky to figure out by experimenting however.

This also means that the cutoff point I described earlier is likely not entirely correct.

Here is a list of the games near the butt end of my SD card, and whether they worked or not.

X = didnt work
\o/ = worked

X 15438931: APOLLO~1NDS 61349920
X 15442701: AGAIN-~1NDS 123519632
X 15444799: LASTWI~1NDS 68747264
\o/ 15445815: ANOTHE~1NDS 33290528
X 15449790: NINEHO~1NDS 130220552
\o/ 15450558: PHOENI~3NDS 25160768
\o/ 15451298: PHOENI~2NDS 24234080
X 15453044: PHOENI~1NDS 57206144
X 15456610: HOTELD~1NDS 116838824
X 15460487: GHOSTT~1NDS 127011808
X 15462352: ACEATT~1NDS 61098016
\o/ 15463245: NINTEN~2NDS 29223936
\o/ 15464137: NINTEN~1NDS 29223936
\o/ 15465225: HARVES~3NDS 35643220
X 15469148: HARVES~2NDS 128542996
X 15470860: HARVES~1NDS 56072292
X 15474798: RUNEFA~1NDS 129019964
\o/ 15475810: ANIMAL~1NDS 33131516
X 15477556: TRAUMA~2NDS 57195914
\o/ 15477992: TRAUMA~1NDS 14267232
X 15481954: SIMS3_~1NDS 129819648
\o/ 15482892: EXITDS~1NDS 30672484
X 15484682: SCRIBB~1NDS 58633943
\o/ 15485633: DRAWNT~1NDS 31128357
\o/ 15485878: N_(USA~1NDS 7998052
\o/ 15486338: SUPERM~1NDS 15049545
\o/ 15486967: NEWSUP~1NDS 20600744
\o/ 15487986: METROI~1NDS 33354272
\o/ 15488314: CLUBHO~1NDS 10706088
\o/ 15489304: WARIOW~1NDS 32426208
X 15491346: GUILTY~1NDS 66862080

EDIT 2:
I got some new insights into the behavior of the bug. Any rom 49 MB or smaller seems basically unaffected and can be played anywhere. It's only at 50 MB that they stop functioning. The cutoff at each size seems to be hovering around the same area however.

X = didnt work
\o/ = worked

\o/ 11392873: ITSUWA~1NDS 50248416
X 11695913: IM3FC4~5NDS 50332704

\o/ 10399740: VIEWTI~7NDS 56687720
X 11283906: JIJITS~1NDS 56927578

\o/ 10712671: YATTER~1NDS 64849920
X 11066460: KAYOUG~1NDS 64818704

\o/ 9790908: TIMEHO~2NDS 128728704
X 11380559: JACKAS~2NDS 128143904

\o/ 10857707: YU91D7~5NDS 254360064
X 11136639: KALLEK~1NDS 249087240
Post automatically merged:

It turns out this bug may be partially my fault. It seems like nds-bootstrap is trying to compress the FAT table of the file, by not listing all contiguous clusters, and simply noting down the start cluster and the amount of adjacent clusters. The utility I wrote to move files however allocated clusters in reverse order, making the cluster cache compress poorly. So not really a nds-bootstrap bug, just an oversight on my part. Sorry for the bother.
Post automatically merged:

Yep, I just flipped the clusters of one rom the right way around and now it works. Problem solved!
 
Last edited by BerelyBecky,
  • Wow
Reactions: ber71

Site & Scene News

Popular threads in this forum