Pcsx2: Marvel Nemesis: Rise of the Imperfects loading hang

[Nobbs66]

Core issue:

Issue title: VU0 hang in Marvel Nemesis: Rise of the Imperfects

-PCSX2 version: 1.3.0 GIT 25-6-2014

-PCSX2 options: Defaults, no settings modifications affect the issue

-Plugins used: GSdx 1.0.0, SPU2-X, LilyPad, Linuz ISO/Gigaherz CDVD, the rest are null plugins

-Plugin settings: Defaults, no settings modifications affect the issue

-Description: On the loading screen before a fight, the game will hang if VU0 is set to anything but interpreter. If VU0 is to interpreter and VU1 is not, then the game will flash some colored shapes after the load screen. If both VUs are set to interpreter, then the game will just show a black screen after the loading screen.

-How to replicate: Go through the menus until you get to the loading screen for the actual battle

-Last known version to work: Never worked

-PC specifications: CPU: Intel Core i7 5820K: Sapphire R9 Fury Tri X OS: Windows 10 Pro 64-bit

Other comments: Bug report on the PCSX2 forums - http://forums.pcsx2.net/Thread-Marvel-Nemsis-Rise-of-the-Imperfects-NTSC-U-Possible-VU-issue

[prafullpcsx2]

Issue title has been copy pasted from a different game and needs to be edited.

[Nobbs66]

@prafullpcsx2 fixed, thanks

[refractionpcsx2]

TBH this is either the VU's are just calculating things completely wrong or it is being sent crap data, difficult to say at this point.

[CyberWolfie]

@Nobbs66 hey, if it's no bother... can you comment on what exactly fixed the problem? Cause i have the same one and i cant seem to fix it :/

[Nobbs66]

you can't fix it

[chuzpz]

I try to play this game in 21/7/2017. But when the game is load the map this automatically pause the game and the game is crashed and the only option to exit for the emulator is force close. Please anyone help?

[refractionpcsx2]

This isn't a support section, if you want help with an unrelated issue please use the forums on forums.pcsx2.net

[MrCK1]

@refractionpcsx2 Here's an ending chunk of the log for Marvel, looks to be a similar situation to the hanging in Iridium Runners

And then here's the top 2 entries in the callstack after the hang:
> pcsx2-dbg.exe!_vu0run(bool breakOnMbit, bool addCycles) Line 66 C++
> pcsx2-dbg.exe!_vu0FinishMicro() Line 75 C++

[MrCK1]

Just pasting Ref's quote for safekeeping. This is what we found a while back on Discord.

hmm so VU0 is waiting for something else to put a value in before it runs the microprogram
That's a bit of a tough situation, if the CPU is waiting on VU0 and VU0 is waiting on something else... that's not gonna happen
we can't pause the CPU
unless we have some way to break VU0 out of its execution and set the CPU PC back
we'd have to simulate a branch
uff, that's annoying :stuck_out_tongue:

[JohnMBrooks]

VU0 is waiting for VU1. Both VUs work together as dual coprocessors for the MIPS CPU with all 3 processors running at 300MHz in lockstep.

I am the author of the Blue Shift PS2 engine used in Marvel Nemesis, WSB 2Kn, and ESPN MLB 2K games.

[refractionpcsx2]

Hi @JohnMBrooks Thanks for replying! Nice to see a veteran here!

From what I recall seeing, VU1 hasn't started yet, in fact VU0 is looping on some memory but also VIF1 is processing in the background. Our problem is that VU0 is processed in a while loop and COP2 is waiting on VU0, which is also a while loop, so the issue we have is that neither of them break free to allow VIF1 to run, which will then probably in turn start off VU1 to make it all happy :)

[JohnMBrooks]

You can check if the MIPS CPU is kicking VU0 alone or starting both VU0+VU1. If both VUs are being kicked directly by the MIPS, the microcode is designed for lockstep execution and the MIPS won't continue until both VUs have stopped. VU0 either waits for VU1 to complete so it can read results from VU1 registers, or the VU0 readback is timed to grab VU1 results after an exact number of cycles.

Some PS2 VU engine code posted in 2017:
https://twitter.com/JBrooksBSI/status/910984656572448769
https://twitter.com/JBrooksBSI/status/911093466725150726
https://twitter.com/JBrooksBSI/status/910890741597036545

VIF1 doesn't kick VU1 for lockstep code, but is used to upload texture data. VU1 is started along with VU0 by the MIPS CPU for 8-way vector SIMD @ 300MHz.

Hope that helps.

[PSI-Rockin]

@JohnMBrooks Thanks for your insight! It's pretty impressive how the engine uses EE+VU0+VU1 effectively as a single SIMD unit.

I investigated this game on my own emulator, which also hung on VU0 reading from a VU1 register. After implementing that, it's able to get past the loading screen, but unfortunately there are major VU issues that make it unplayable:

• Near the end of vertex processing, the EE seems to start multiple VU1 microprograms through CMSAR1 without waiting for VU1 to end. The manual says that writes to CMSAR1 should be ignored when VU1 is running. Doing this causes the XGKICK transfer to be corrupted, as one of the microprograms is responsible for writing the end tag for the transfer. Is the EE code timed properly on real hardware for the VU1 micros to end?
• If I stall the EE upon successive writes to CMSAR1 while VU1 is active, the XGKICK transfer is completed normally. However, SPS covers the screen, and it is impossible to make out any geometry, although I was able to see a road texture in one instance. Your comment says that VU0 will read VU1 results after a certain number of cycles have passed. Currently, my emulator does not sync VU0 and VU1 together when VU0 reads from a VU1 register, which would cause VU0 to read results before it is supposed to. Are there any other instances of timed code?

Thanks for your help!

[JohnMBrooks]

Each loop iteration, the MIPS CPU starts both VU0 and VU1 together on the same clock cycle via vcallms + ctc2. Both VUs run code which take the same number of cycles so they end/exit at the same time.

Notes:

• VU0 and VU1 must be started together on the same CPU cycle and run in sync
• VU0 can read and write VU1 registers while VU1 is running (VU0 does not stall on VU1 access).
• VU1 polls GS status and does an XGKICK only when GS is idle so that VU1 will not stall

Hope that helps,
-JB

[kozarovv]

Hello. Loading hang can be fixed on pcsx2 by enabling this code in iR5900-32.cpp for retail build:

https://github.com/PCSX2/pcsx2/blob/6e22efe790a99d9750b407acd4690cc8b93d34d5/pcsx2/x86/ix86-32/iR5900-32.cpp#L1057
https://github.com/PCSX2/pcsx2/blob/6e22efe790a99d9750b407acd4690cc8b93d34d5/pcsx2/x86/ix86-32/iR5900-32.cpp#L1384

Anyway it will face the same issue as @PSI-Rockin pointed as second in his post above. At least visually so only heavy SPS will be visible. Maybe it will help somehow with research.
Just in case, i tested also with enabled mbit handling, there seems to be no difference.

[VinnieTeix]

Hello. Loading hang can be fixed on pcsx2 by enabling this code in iR5900-32.cpp for retail build:

https://github.com/PCSX2/pcsx2/blob/6e22efe790a99d9750b407acd4690cc8b93d34d5/pcsx2/x86/ix86-32/iR5900-32.cpp#L1057

https://github.com/PCSX2/pcsx2/blob/6e22efe790a99d9750b407acd4690cc8b93d34d5/pcsx2/x86/ix86-32/iR5900-32.cpp#L1384

Anyway it will face the same issue as @PSI-Rockin pointed as second in his post above. At least visually so only heavy SPS will be visible. Maybe it will help somehow with research.
Just in case, i tested also with enabled mbit handling, there seems to be no difference.

Hello, would you mind explaining the process of enabling this code to newer users on pcsx2 like me? Thanks

[MrCK1]

Closing this since the loading hang has been fixed. In-game graphics are still broken however.