Game crashes after second cutscene in The World Ends With You

[SleepyLark]

When playing the game for the first time, you have to do a quick tutorial fight, after which a cutscene will play. A little while after it plays the game will crash and the music will get stuck. Before it does crash, it appears that the top and bottom screens are slightly off sync (if that helps). The only way around it is to import a save from either DraStic or DeSmuME from after that cutscene.

[ghost]

Oh wow, how did I not see this issue sooner?

Supposedly this game spams the B8 command as some weird form of anti-piracy, it caused game crashes on older flashcarts or those with slow enough SD cards. There was a recent-ish commit which made fixes to cart timings, and it may have fixed this bug (it's not too unreasonable to assume that this weird from of AP could also trip up emulators which don't properly emulate this.)

If you can compile melonDS yourself you may be able to try it out and see if it works. Otherwise I might still find the time to set up the build environment for it on Windows so I can do it myself, but setting up Code Blocks and SDL2 for compiling melonDS has been a royal pain in the past, so I'm not looking forward to having to do that.

[Arisotura]

command B8 is for getting the cart's chip ID. games typically check it against the value stored in RAM every once in a while, to check whether the cart was ejected.

I don't quite see how that would break TWEWY unless it expects a specific chip ID value.

[ghost]

As far as flashcarts go, supposedly B8 is used to stop SD traffic to save battery life, but causes the SD to lockup if spammed too much, and I guess faster SD cards are able to handle it without locking up.

https://gbatemp.net/threads/the-world-ends-with-you-u-crash-in-beginning-cutscene.222788/#post-2780571

As far as emulator goes, who knows. This is assuming that this is even the same thing that causes the crash in melonDS.

[Arisotura]

have a savefile close to the crashing spot?

[ghost]

It happens before you get to save for the first time. It only takes a few minutes to get there though (unless you want a save state, I can do that.)

[Arisotura]

savestate w/ latest melonDS would be cool, yea

[ghost]

twewy.zip

[Arisotura]

thx

[Arisotura]

loading that savestate causes a flood of 'unknown ARM9 write 00000xxx', do you also get those?

[ghost]

This happens regardless of save state, whenever there is a cutscene with characters talking in speech bubbles, and there is a still image showing on the bottom screen (as opposed to the bottom screen just being darker and showing the NPCs in the background, if that makes sense.)

[Arisotura]

DMA func 0203ADB4 ARM9 DMA3 84001800 00 0228A640->EA20C301 24576 bytes 32bit

it's attempting to transfer graphics (the size of 24576 bytes would be exactly one screen worth of 16-color graphics) but the destination address is wrong

[Arisotura]

ok well, it's getting a pointer from 0x023C9B4C to do shit

and that pointer is NULL

[Arisotura]

also: can ya test older melonDS versions (0.7.1, 0.7 and older) to see if it behaves the same?

[Arisotura]

nevermind.

history indicates this is a big fat timing issue, which is confirmed by tweaking the cache memory timings in CP15.cpp. setting them to lower values fixes the issue.

[RSDuck]

this could be related to cartridge timing as well. Making the transfer faster fixes this as well.

Also the arm9timinghax branch doesn't fix this, which doesn't say that much, but the thing is that on average we already run the ARM9 too fast, so an even lower value seems fishy to me.

EDIT: allegedly flashcards with too slow sd cards used to have this issue as well. That would be a point for the cartridge timing theory.

[zaloh]

Based on a suggestion in this thread, I changed the game setting in DSiMenu++ to DSi mode; which fixed the crash. https://github.com/DS-Homebrew/nds-bootstrap/issues/235#issuecomment-649173856

[RSDuck]

My guess is that with nds-boostrap the sd card is too so cartridge timings are off which is balanced out by making the processor faster. And in melonDS the arm9 memory timings are just completely off.

[Soleyu]

I ran into this issue myself and I was reading about it, and it appears medusa dealt with the issue already, I dunno whats the policy here about talking about what other emulators have done, so for now Ill refreain from saying it or linking to it in case that is a problem of some kind, of course if its i ok I can link to the commit that fixes it (though I dont know if that is all that would be needed considering that the emulators are different)

[poudink]

are you talking about this? https://github.com/mgba-emu/mgba/commit/f32fbd737fee9defcfbbb73a386685f936eeaae5

[Soleyu]

yes thats the one, though as I said I dont know how much that will help since they are different emulators after all.

[RSDuck]

I dug out Arisotura's old icache implementation and using it, it works as well.

[Stevoisiak]

It's worth mentioning this also occurs if you beat the main story and replay Day 1 through the chapter select.

[tuy360]

Also had this error.

[Pwnzer2000]

You can rapidly open/close lid to get past the crash. Just start right before the crash and (to be safe) try stopping when Joshua shows up.

[VBANoobie]

Sorry, new to GitHub in general and didn't know this was a thing, has anyone found a fix? I'm kinda having trouble understanding some of the terminology being used here, anyone have a simpler explanation on how to fix the issue on MelonDS?

[Sanaki]

Options:

• Use a custom build specifically for that game (no, one is not available, you'd have to compile it)
• Repeatedly hammer the lid close button through the crash-inducing cutscene
• Use the provided save file up above
• Wait for a fix (may take a while still)