Project

General

Profile

Emulator Issues #5336

Star Wars Rogue Squadron III: Rebel Strike - Fails to boot with JIT64/JITIL

Added by tommyhl2.SS about 8 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
PPC
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

1) Game Name and ID (as it appears in right click > properties: "GZ2P01",
"RSBE01", etc):

GLRE64

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
problem began.

Never worked.

4) What steps will reproduce the problem?
1.Load the game, wait, wait...
2.Nothing happens after the first text screen
3.

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).

http://img233.imageshack.us/i/rs33.jpg


Related issues

Has duplicate Emulator - Emulator Issues #6024: SW Rebel Strike: Dolphin dies immediately...Duplicate

Has duplicate Emulator - Emulator Issues #6530: Star Wars Rogue Squadron III: Rebel Strike – PAL - FrancaisDuplicate

History

#1 Updated by pierre about 8 years ago

With full MMU, BAT and PPC Emulation set to interpreter, the first screen fades to black.

After that, we get the attached message via OSREPORT.

#2 Updated by parlane about 8 years ago

Woo mmu and/or interpreter issue!!! Where is booootooooooo.

#3 Updated by parlane about 8 years ago

Do you get that osreport when not using mmu ?

#4 Updated by tommyhl2.SS about 8 years ago

Skid is the MMU guy, CC him first. :p

#5 Updated by parlane about 8 years ago

He isn't, booto secretly is!

#6 Updated by parlane about 8 years ago

But sshhh, don't tell anyone!

#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.

#8 Updated by skidau about 8 years ago

I suspect the problem is in the TLB cache. The number of entries in the cache and how they are being flushed is not accurate to the real hardware.

#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).

#10 Updated by skidau about 8 years ago

Thanks, tueidj. I will work on the R and C bit emulation as that is also not accurate in the current MMU emulation.

#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.

#12 Updated by parlane about 8 years ago

tueidj, why u no join the dolphin side O:)

#13 Updated by parlane about 8 years ago

Are you suggesting this worked in r4?

#14 Updated by marcosvitali almost 8 years ago

FOREVER AND EVER!!!

#15 Updated by tommyhl2.SS almost 8 years ago

Thanks for the input, marcos. :p

#16 Updated by delroth almost 8 years ago

  • Status changed from New to Work started

Fixed in interpreter mode by r30de244050d5. Needs to be fixed in jit64 and jitil.

#17 Updated by tommyhl2.SS over 7 years ago

issue 6024 has been merged into this issue.

#18 Updated by Billiard26 over 7 years ago

  • Issue type set to Bug
  • Category set to ppc

#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 ;)

#20 Updated by shingimel almost 7 years ago

joining the question above

#21 Updated by skidau almost 7 years ago

issue 6530 has been merged into this issue.

#22 Updated by sandrarealdelnoval over 6 years ago

I´m a totally neofit player that use your amazing emulator.
Do you think that the game will work properly anytime?
Thanks for your efforts and your work.
Greetings from Spain.

#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.

Also available in: Atom PDF