TASEmulators
"Rabbids Go Home" freezes after logo
Every time I try to load Rabbids Go Home it shows the ubisoft logo and freezes on a black screen with no audio. After it sits for a bit, In the second window it says “ARM9: undefined instructions: 0xEA000075 PC=0x02004000” . This is the only game that does this
I looked around for answers but couldn't find any fixes. Im not great with these sorts of errors so a slightly more detailed suggestion or fix would be greatly appreciated
Works fine for me. Stop using a million years old version of desmume or cheating or patching, or else make sure your rom isn't corrupted.
It appears the game seems to have a copy protection mechanic. The game runs 100 rom reads of 0x4000 bytes and times how long will it take. The loading time must take around 80000 and 88000 ticks (152 to 168ms) or the game will hang before the title screen. The game does not use the DSProtect anti-piracy library, it is using a custom copy protection mechanic. DeSmuME does not emulate this loading precision so for the game to work when the game crashed one must use an action replay code to bypass load check
That's useful information, but then why do my notes from 3 years ago say it worked just fine for me?
Welp, the game crashes for me, maybe should add a commit to emulate this load precision or implement a cheat code to get it working
Oh, interesting. It freezes at the black screen when you try to create a new game, but at the point OP mentioned when it boots with the save data already created.
If you can find a way to fudge the timing, we can hardcode it as a per-game hack. I think the rom loading time has a few knobs and levers
If you can find a way to fudge the timing, we can hardcode it as a per-game hack.
maybe the most effective solution would be an in-memory patch of the rom skipping the copy protection code entirely ?
Well. I say should adjust the actual rom read timing down to 159ms between 152 to 168ms for this game, or an action replay code.
In-memory patch is not a bad idea but it's tricky (needs to work for both HLE and firmware boot). Might could be done in the slot-1 system as a kind of "overlay" that will check a list of ranges and substitute as-needed on the fly.
If we make some way to force an AR code separately from the user-entered ones, that seems like a versatile tool.
"Adjust the actual rom reading time" doesn't sound easy. It's emergent behavior from complex code.
Okay, adjusting is complex. Just for now, you either use DS-Scene Rom Tool with my updated custom database or use action replay code for the game to work.
US: 5203CF18 E28DD02C 0203CF18 EB0F0878 D2000000 00000000 023FF100 E59D1000 E23FF104 00000030 E3510001 1A000003 E28F1010 E891001E E5813000 E5824000 E28DD02C E12FFF1E 0218D5C4 0218D5CC E3A05921 E3A04000 D2000000 00000000
EUR: 5203D108 E28DD02C 0203D108 EB0EFCBC D2000000 00000000 023FF100 E59D1000 E23FF104 00000030 E3510001 1A000003 E28F1010 E891001E E5813000 E5824000 E28DD02C E12FFF1E 0218DA4C 0218DA54 E3A05921 E3A04000 D2000000 00000000
thanks for those codes. i took the liberty to run them through my ar2c.py and this is the result:
void cheat_us() {
u32 offset = 0;
u32 datareg = 0;
u32 loop = 0;
if (0xe28dd02c == *((u32*)0x203cf18)) {
*((u32*)0x203cf18+offset) = 0xeb0f0878;
flush();
} // next/flush
offset = 0;
datareg = 0;
*((u32*)0x23ff100+offset) = 0xe59d1000;
memcpy((void*)(0x23ff104+offset), "\x01\x00\x51\xE3\x03\x00\x00\x1A\x10\x10\x8F\xE2\x1E\x00\x91\xE8\x00\x30\x81\xE5\x00\x40\x82\xE5\x2C\xD0\x8D\xE2\x1E\xFF\x2F\xE1\xC4\xD5\x18\x02\xCC\xD5\x18\x02\x21\x59\xA0\xE3\x00\x40\xA0\xE3", 48);
flush();
}
void cheat_eu() {
u32 offset = 0;
u32 datareg = 0;
u32 loop = 0;
if (0xe28dd02c == *((u32*)0x203d108)) {
*((u32*)0x203d108+offset) = 0xeb0efcbc;
flush();
} // next/flush
offset = 0;
datareg = 0;
*((u32*)0x23ff100+offset) = 0xe59d1000;
memcpy((void*)(0x23ff104+offset), "\x01\x00\x51\xE3\x03\x00\x00\x1A\x10\x10\x8F\xE2\x1E\x00\x91\xE8\x00\x30\x81\xE5\x00\x40\x82\xE5\x2C\xD0\x8D\xE2\x1E\xFF\x2F\xE1\x4C\xDA\x18\x02\x54\xDA\x18\x02\x21\x59\xA0\xE3\x00\x40\xA0\xE3", 48);
flush();
}
note that my tool raises an exception on the last command: "next without for" so the AR codes might be buggy.
wow! this is a really cool concept! I'm inclined to add an apparatus for using per-game hacks like this in desmume. But
- can you investigate the exception?
- what's flush() supposed to do?
- uhmmm also it seems wrong. offset is always 0 and what are datareg and loop? seems related to the loop-related exception
can you investigate the exception?
i think it's just one superfluous command at the end, AR devices and AR emulators will probably just ignore it, though i can look at it in more depth
what's flush() supposed to do?
afaik it just writes immediately to memory, kinda like fflush() immediately writes buffered stuff to the file's fd. i'm inclined to think that the first flush call is unnecessary since the 2nd one is called unconditionally, though on a real AR device AR code might be executing in parallel with game code, in which case it might be necessary
uhmmm also it seems wrong. offset is always 0 and what are datareg and loop? seems related to the loop-related exception
these are some variable the AR bytecode uses so my converter just always zero-initializes them, just in case. there's no optimizer pass to remove unnecessary operations.
What do you think of this? Seems to work great for rabbids (I only tested US) and be solid for the future
I tested both US and EU versions of this game for commit a0b088e. With "Use Game-Specific Hacks" enabled, they both seem to work for me, as I can successfully get past the title screen and start a new game. With "Use Game-Specific Hacks" disabled, they both get stuck at a black screen as noted above.
Hello. The new AP fix for my updated DS-Scene Rom Tool database was made by taxicat1, who worked on reversing the copy protections for DS, DSProtect and MetaFortress. He says that the copy protection uses 100 DMA reads that is done on startup and as before the game hangs when time is not in a certain range. Maybe a new and better fix might be implemented to improve the DMA read emulation for this game instead of patching in with AR codes.
Maybe a new and better fix might be implemented to improve the DMA read emulation for this game instead of patching in with AR codes.
in that case it would certainly be preferable that DMA read timing is generally more accurate, and if it fixes this game as a result it would be a nice side-effect.
The game runs 100 rom reads of 0x4000 bytes and times how long will it take. The loading time must take around 80000 and 88000 ticks (152 to 168ms) or the game will hang before the title screen.
do you know the actual time it takes with desmume ?
The game runs 100 rom reads of 0x4000 bytes and times how long will it take. The loading time must take around 80000 and 88000 ticks (152 to 168ms) or the game will hang before the title screen.
do you know the actual time it takes with desmume ?
Umm . . no.
Update: Turns out that the actual load time that the custom copy protection must take is 1001 to 1063ms, not 152 to 168ms.
DSProtect's testing loading time on DeSmuME is 35ms.