Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Game crashes after second cutscene in The World Ends With You #380

Open
SleepyLark opened this issue Feb 16, 2019 · 27 comments
Open

Game crashes after second cutscene in The World Ends With You #380

SleepyLark opened this issue Feb 16, 2019 · 27 comments
Labels
timing Timing issue

Comments

@SleepyLark
Copy link

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
Copy link

ghost commented Apr 11, 2019

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
Copy link
Member

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
Copy link

ghost commented Apr 15, 2019

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
Copy link
Member

have a savefile close to the crashing spot?

@ghost
Copy link

ghost commented Apr 27, 2019

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
Copy link
Member

savestate w/ latest melonDS would be cool, yea

@ghost
Copy link

ghost commented Apr 27, 2019

twewy.zip

@Arisotura
Copy link
Member

thx

@Arisotura
Copy link
Member

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

@ghost
Copy link

ghost commented Apr 27, 2019

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
Copy link
Member

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
Copy link
Member

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

and that pointer is NULL

@Arisotura
Copy link
Member

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

@Arisotura
Copy link
Member

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.

@Arisotura Arisotura added the timing Timing issue label Apr 27, 2019
@RSDuck
Copy link
Member

RSDuck commented Aug 9, 2020

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
Copy link

zaloh commented Dec 2, 2020

Based on a suggestion in this thread, I changed the game setting in DSiMenu++ to DSi mode; which fixed the crash.
DS-Homebrew/nds-bootstrap#235 (comment)

@RSDuck
Copy link
Member

RSDuck commented Dec 2, 2020

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.

@SuperSamus
Copy link

For those who want to play before the issue is solved, here is a save file from Day 2 (past that cutscene):
TWEWY - Day 2 Save.zip

@Soleyu
Copy link

Soleyu commented Jan 18, 2021

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
Copy link

poudink commented Jan 18, 2021

are you talking about this? mgba-emu/mgba@f32fbd7

@Soleyu
Copy link

Soleyu commented Jan 18, 2021

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

@RSDuck
Copy link
Member

RSDuck commented Feb 24, 2021

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

@Stevoisiak
Copy link

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

@tuy360
Copy link

tuy360 commented Jun 19, 2021

Also had this error.

@Pwnzer2000
Copy link

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
Copy link

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
Copy link

Sanaki commented Sep 20, 2021

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
timing Timing issue
Projects
None yet
Development

No branches or pull requests