[N64] Jet Force Gemini and Mickey Speedway USA: Crashes in intro

[Shideravan]

The game crashes in the intro, showing the following message

ares e6948d2

[Shideravan]

Another Rareware game with the same crash in intro (the issue is probably related):

[remutro]

Confirmed, both problems are known.

[kev4cards]

I reported the Jet Force Gemini crash before in the now-defunct ares repository. In my case with ares v119r2, the error happened at a different point in the intro. Also, the code was different (SP crashed, gfx=802239a0 version 9.6). I believe the problem cleared itself up for a short while between major releases without a known reason as to why or how. It was and still is my understanding that the problem is likely related to RSP timing.

[Shideravan]

ares da53c2b Now it's giving a different code

But for Mickey's Speedway USA the code is the same as before

[kev4cards]

Mickey's Speedway USA has been fixed since commit bcf9cab. Jet Force Gemini remains unchanged,

[kev4cards]

Mickey's Speedway USA has regressed back to the way it was as of commit 57b4d68.

[Shideravan]

a new code for Jet Force Gemini in v129 50b2a8f

Mickey's Speedway USA shows the same code

[loganmc10]

This happens in m64p as well. I notice that the game sets the SSTEP (single step) bit right around when this happens.

It doesn't look like Ares implements single step mode for the RSP, I think MAME has an implementation of it, but I'm not sure if it's correct.

[loganmc10]

After looking into this a bit, I think the RSP just be going into single step mode in order to print that debugging message. It seems like the problem starts when the CPU sets SIG0 (requesting the RSP to yield). If I shorten the RSP timing in m64p, the yield is never requested, and the video never freezes. So it may just be a general CPU/RSP timing issue

[invertego]

These games contain the following timing test which fails unless PI DMA and RSP pipeline stalls are emulated very precisely. The value in a1 is a loop counter used in a busy wait for PI DMA completion. The Zelda games contain the same code, though they manifest different errors when the test fails.

06c  srl     v1,a1,12
070  subi    v0,v1,$4c
074  bltz    v0,$cc
078  subi    v0,v1,$4f
07c  bgtz    v0,$cc

With recent (#1147) and upcoming (#1149) changes, ares will have sufficiently accurate timing to pass this test.

[Ryan-Myers]

These games contain the following timing test which fails unless PI DMA and RSP pipeline stalls are emulated very precisely. The value in a1 is a loop counter used in a busy wait for PI DMA completion. The Zelda games contain the same code, though they manifest different errors when the test fails.

06c  srl     v1,a1,12
070  subi    v0,v1,$4c
074  bltz    v0,$cc
078  subi    v0,v1,$4f
07c  bgtz    v0,$cc

With recent (#1147) and upcoming (#1149) changes, ares will have sufficiently accurate timing to pass this test.

Sorry for reviving something a year old, but do you know where in the ROM of JFG this assembly occurs? I'm investigating JFG with a decompilation project and I can't seem to find that snippet of code. It's entirely possible it's hard for me to find it due to differences in disassembly, so it might help if you could provide more details as to where in the ROM this code occurs.

[invertego]

@Ryan-Myers Offset 0x9FEBC in the retail USA ROM. Here it is again with the instruction bytes:

06c  00051b02  srl     v1,a1,12
070  2062ffb4  subi    v0,v1,$4c
074  04400015  bltz    v0,$cc
078  2062ffb1  subi    v0,v1,$4f
07c  1c400013  bgtz    v0,$cc