Emulator Issues #5336
Star Wars Rogue Squadron III: Rebel Strike - Fails to boot with JIT64/JITIL
1) Game Name and ID (as it appears in right click > properties: "GZ2P01",
2) What is the expected output? What do you see instead?
The game should load passed the first text screen, but it does not.
3) Did the game ever work correctly (i.e. not have this problem) on an
earlier version of dolphin? Please specify the exact revision when the
4) What steps will reproduce the problem?
1.Load the game, wait, wait...
2.Nothing happens after the first text screen
5) What version of dolphin are you using (32bit/64bit along with the
version as it appears in the title bar, etc)? Do not say 'latest version'
this changes multiple times a day.
On what operating system, drivers, and hardware? Be sure to list OS,
graphics driver information, and video card model if you are having
graphics problems, for example.
Asus Laptop: K53TA
OS: Windows 7 Home Premium, 64-Bit - SP1
CPU: AMD A6-3400M, Quad-Core, 2.3GHz-2.6GHz
GPU: AMD Radeon HD6650, 1GB GDDR3
RAM: 4GB DDR3
r5 to 3.0-496
6) Please provide any additional information below.
Stock .ini settings for this game should be good enough to get where the game will not proceed.
7) Attachments. IMPORTANT! We have a limited storage quota on
GoogleCode, so please use a 3rd party host for screenshots or any other
files (http://min.us/ for example).
#7 Updated by pierre about 8 years ago
MMU Speed hack makes it just freeze at the opening screen. No MMU => crash.
This game uses real virtual memory, that is, it maps a portion of physical memory to varying addresses in the 0x7fxxxxxx range(thus needing a fully emulated MMU). The game uncompresses data on demand in some fault-handler for the "virtual" addresses. It is this handler, that gives the osreport, after it worked correctly for a while.
#9 Updated by tueidj about 8 years ago
Actually this game is extra clever, it creates a virtual range of 32MB and segments it for both code and data:
--- GSYS VM init ---
Original arena: 0x800ac900 - 0x817fe7c0
Found compressed VM data at 80200000 (2152886 bytes)
Found boot user data at 80680000 (473728 bytes)
VM memory management table is at 0x800ad000
ARAM management at 0x800b3a80, effective address ARAM mapping at 0x800bbe80
33554432 bytes of virtual memory setup at 0x7e000000 using 4653056 bytes of physical memory at 0x000e0000
VM physical page priority evaluation active.
Adding 57344 bytes of physcial memory to VM system (PageTable gap)...
Decompressing VM data... (2152886 bytes -> 6307168 bytes)
Copying 4617568 bytes of text section data to 0x7f200000...
Copying 124480 bytes of data section data to 0x7f668000...
Copying 1564864 bytes of data section data to 0x7f687000...
Clearing VM BSS area at 0x7f806000 (428704)...
VM Data copy finished.
User VM heap reserved from 0x7e000000 to 0x7f200000
Truncated arena: 0x80550000 - 0x817fe6c0
--- GSYS VM init done ---
Exactly how it manages to map 32MB of VMEM to 16MB of ARAM I'm not sure. Maybe it just never uses more than ~9MB of the "User VM heap".
Accurate emulation of the TLB cache shouldn't be necessary, but what does need to be correct is updating the R and C bits of PTEs - the C bit is used to know if a page has been modified and needs to be written when paged out (this is common) and this game also seems to play with the R bit as part of an algorithm (see the reference to "page priority") to decide which pages to switch out (not so common).
#11 Updated by tueidj about 8 years ago
Something else I just thought of that may or may not be relevant for this game (but definitely is for others e.g. Ultimate Spider Man): pages can be mapped as read-only, in which case any stores to those pages should set bit 4 in DSISR (protection violation) instead of bit 1 (page fault) when taking the DSI exception.
#19 Updated by irwin.matt over 7 years ago
I was really excited to read these developer comments below the submitted issue report, but what isn't clear is if this game works or not. On the official dolphin game thread it says that the game is broken. Is that still true? Please, for the love of everything co-op, outsmart r2d2 and hack this thing. i will send a reward of 10 argentine pesos in the mail as soon as it's done ;)
#23 Updated by animedude5555 over 6 years ago
Still broken as of 3.5, and even worse the fix (albeit less than ideal) recommended in the Wiki for Dolphin on the page for this game, (that worked supposedly back in version 3.0 of Dolphin, by using MMU, MMU Speed Hack, and Interpreter) doesn't work in 3.5 Dolphin.
PLEASE FIX THIS!
#25 Updated by JMC4789 over 5 years ago
- Status changed from Work started to Fixed
Rebel Strike (PAL) Boots successfully in Master, and we have reason to suspect the reason it doesn't boot is unrelated to CPU (PAL60 also breaks it for the PAL version)
This behavior of constantly crashing/failing changing into being somewhat playable seems to be been spurred between when Fastmem Writes were merged (breaking the game completely) and when the Mem1 check (https://dolphin-emu.org/download/dev/74f8a48ee6e967d9c46212fa48cd6392fdc9683f/) fixing that crash. As of that point, Rebel Strike successfully boots, and doesn't seem to suffer any 100% crashes, but it has literally tons of random crashes and CPU bugs still.
As of 4.0-3232, Rebel Strike loads and is technically somewhat playable in Dolphin on the PAL version.
#26 Updated by JMC4789 over 5 years ago
NTSC Versions fixed as of 4.0-3473 (https://dolphin-emu.org/download/dev/19fbefd9bd11536b797542f763a53d5aaeb27893/)