SP DMA segmentation faults in Neon Genesis Evangelion about project64

[cxd4]

Update--only happens in HLE gfx + LLE audio??

Running the RSP in LLE gfx, there is no SP DMA crash (which I find odd).
Changing graphics plugin doesn't seem to matter (duh).

It's just HLE gfx && LLE audio, that the SP DMA errors 3 times, if you click OK all 3 times it's like nothing ever went wrong. So this is a very minor bug/inconvenience in the RSP recompiler I think, as interpreter does not have it.

[cxd4]

R4300 CPU interpreter does not affect the issue, just whether RSP is recompiled or not.

32-bit Engine RDB setting affects whether or not I can get the saved state to load in the first place, beyond that not sure.

[LegendOfDragoon]

Well, judging by the testing I've done, I don't think it's an opcode issue. There are some strange things about the RSP recompiler that I recently noticed. For instance, for some games, it will recompile the same block multiple times. I will try investigating stuff like that in the near future.

[cxd4]

It probably is a very subtle and indirect cause.

After all it only happens if (gfx == HLE && aud == LLE) ... any other combination of HLE/LLE for RSP graphics/audio seems to not have this recompiler bug. And even then all you have to do is click OK on the 3 or 4 SP DMA errors and there is no corrupt audio or graphics. So this is a very minor bug indeed, but with an interesting subtle cause it would seem.

[LegendOfDragoon]

I forgot to mention that I get them regardless of whether HLE gfx or LLE gfx.

[cxd4]

It has to be HLE gfx. I never get them in LLE gfx. Make sure your per-ROM LLE/HLE gfx setting matches the global one.

Using the default RDB settings from the repo.

In fact now that I just loaded up his saved state in the current build of the RSP recompiler plugin, I'm getting SP DMA error messages even more frequently now. Before I had to wait for my dude to lose all his health and die. Now it happens every time I'm attacked. Once again the SP DMA errors are not fatal and can be ignored by hitting OK or Enter enough times. [EDIT] Yeah scratch that it doesn't happen every single time. Yeah there's some random stuff going on in this dynarec.

[LegendOfDragoon]

Odd, now I'm getting a different type of error. I made sure it was LLE by also trying out your RDP fork. Wow lol, now I'm having trouble with save states ;/ .

I don't use that save state he provided anymore, since I got the error more consistently when I start mission 12. For some reason, I get a different error now ;/ . It says "Break point found at N64 System\Mips\Memory Virtual Mem.cpp 1618. Followed by "CN64System::RunRSP Unknown Memory Action Emulation Stop" . I guess I will try debugging the RSP.

Edit:I'm totally confused now. Keep getting strange results. I'll do more testing.

[LegendOfDragoon]

Ok I shouldn't have assumed Azimer's HLE audio was stable for this game. So those weird errors I got, were due to something else and not PJ64's RSP.

Basically the errors happen with LLE audio, doesn't matter whether HLE or LLE gfx. That much I know for certain. Now if I could find a good way to trace, I'd be able to track down the problem. I'm probably better off looking at source and seeing which part of the recompiler is inconsistent with interpreter.

[cxd4]

Or you could go the automative approach and implement a system that compares all the state machine properties of the RSP interpreter, to that of the RSP recompiler, and contrasts any differences between them as they both run and asserts an error message.

Though I'm afraid implementing a debugger for comparing the recompiler against the interpreter might saturate what dependencies on this little-endian storage of the RSP vector elements we already have, duplicating the same mess. I wonder how hard it would be to just convert the whole RSP plugin to big-endian now, before it's too late or gets even harder in the future, but I guess that's really a separate conversation.

I would prefer to debug it with HLE graphics, so that the graphics ucodes don't interfere with debugging the audio ones which are really the issue.

[LegendOfDragoon]

That's not a bad idea to compare recompiler with interpreter at run time.

I too prefer debugging this issue with HLE graphics. Now I'm not sure what even causes this error because even cpu interpreter + rsp interpreter gave me the error (HLE gfx, LLE audio). I don't use a save state anymore. I just disable frame limiter and start mission 12.

I actually tried the original save state again and also got the error with both cpu & rsp interpreter enabled.

Honestly, I don't get why it checks if (addr > 0x800000). I'd imagine it should check if (addr >= 0x800000). But even that isn't thorough enough, based on the idea of not reading past 0x800000. So I don't even know what to do. Another thing is that the game uses a fairly common audio ucode.

[project64]

the r4300 already has the option of comparing the recompiler and the interpreter.

I had thought more of doing something similar for the rsp, doing it in the core tho, where I execute instead of the whole rsp task in one hit, like to a jump/jump backwards. One of the version would run the recompiler the other interpter, Then export the internal variables and compare those after each block.

[cxd4]

Now I'm not sure what even causes this error because even cpu interpreter + rsp interpreter gave me the error (HLE gfx, LLE audio). I don't use a save state anymore. I just disable frame limiter and start mission 12. I actually tried the original save state again and also got the error with both cpu & rsp interpreter enabled.

That does sound interesting. If you find any consistent steps for me to trace to see that this is a RSP interpreter bug then I would be happy to look at it. Occasionally it is plausible that a game will try to write to an unmapped RDRAM address--but, usually only to determine if the 8 MB expansion pak is installed. I'm not sure that the game is seriously meaning to demand SP DMA on an unmapped 16-MB-address test for some arbitrary reason, as there is no officially available 16-MB expansion pak accessory for the N64 (unless you follow the homebrew channels). So I would have to carefully make sure that it's doing this on purpose and on other emulators to try hard to make sure this isn't just caused by the Project64 CPU.

[cxd4]

Do you still find it's a RSP/CPU interpreter issue and not with recompiler @LegendOfDragoon ?
Or has that perhaps been disproven in one of your recent tests

[LegendOfDragoon]

Well, I know for certain it's not only a recompiler issue. Unsure if it's a CPU or RSP problem, but I'm leaning toward CPU since the game uses a common microcode for audio. I haven't figured out a good way to do tracing. I'll try doing more testing today though.

I got those DMA errors regardless of whether I used interpreter or recompiler for both RSP and CPU.

[cxd4]

I sometimes wish saved states were compatible across each N64 emulator, don't you?

That way you could test this game on other interpreters besides Project64's, to get a better idea whether it's a VR4300 issue or a RSP issue with interpreting.

The microcode may be common, but the main CPU is still able to DMA code to IMEM and that didn't stop Gauntlet Legends from doing funky timing stuff with the RSP, despite using the common F3DEX microcode. So this could be another RSP interpreter issue with pj64 but then there are other valid explanations besides that.

If there's anything I can do to help debug or analyze you can join #project64 and we can troubleshoot it.

[cxd4]

Already reposted this issue in more detail here at #57 .
Which is way easier to reproduce consistently right after boot with fixed audio, than this game.

And anyway I think it may be a RSP plugin issue, not a pj64 issue.