New dynarec and F-Zero X Expansion Kit hacked rom

[dmrlawson]

Hi,

I'm trying to get the F-Zero X Expansion kit cartridge hack to work the new dynarec. It works with the old one but not the new one.

If I compile mupen64plus-core with DEBUG=1 it fails on an assert:

$ mupen64plus NUD-EFZE-JPN.n64 
 __  __                         __   _  _   ____  _             
|  \/  |_   _ _ __   ___ _ __  / /_ | || | |  _ \| |_   _ ___ 
| |\/| | | | | '_ \ / _ \ '_ \| '_ \| || |_| |_) | | | | / __|  
| |  | | |_| | |_) |  __/ | | | (_) |__   _|  __/| | |_| \__ \  
|_|  |_|\__,_| .__/ \___|_| |_|\___/   |_| |_|   |_|\__,_|___/  
             |_|         https://mupen64plus.org/               
Mupen64Plus Console User-Interface Version 2.5.9

UI-Console: attached to core library 'Mupen64Plus Core' version 2.5.9
UI-Console:             Includes support for Dynamic Recompiler.
Core: Using full mem base
Core: Goodname: F-Zero X Expansion Kit (U) [CART HACK]
Core: Name: 
Core: MD5: 5932D07D6AAA84B7D74F5251D8942C91
Core: CRC: C6E39C0A D2726676
Core: Imagetype: .z64 (native)
Core: Rom size: 66551504 bytes (or 63 Mb or 504 Megabits)
Core: Version: 2B9142F
Core: Manufacturer: 261343
Core: Country: USA
UI-Console Status: Cheat codes disabled.
UI-Console: using Video plugin: 'Glide64 Video Plugin' v2.0.0
UI-Console: using Audio plugin: <dummy>
UI-Console: using Input plugin: <dummy>
UI-Console: using RSP plugin: 'Z64 RSP Plugin' v2.0.0
Video: SSE detected.

RSP Status: INITIATE RSP
Core Warning: No audio plugin attached.  There will be no sound output.
Core Warning: No input plugin attached.  You won't be able to control the game.
Core: Using video capture backend: dummy
Core: Game controller 0 (Standard controller) has nothing plugged in
Core: Game controller 1 (Standard controller) has nothing plugged in
Core: Game controller 2 (Standard controller) has nothing plugged in
Core: Game controller 3 (Standard controller) has nothing plugged in
Core: Using CIC type 5167
Video: opening /usr/local/share/mupen64plus/Glide64.ini

Video: opening /usr/local/share/mupen64plus/Glide64.ini

Video: fb_clear 0 fb_smart 0

Video: extensions 'CHROMARANGE TEXCHROMA TEXMIRROR PALETTE6666 FOGCOORD EVOODOO TEXTUREBUFFER TEXFMT'

Video: fb_hires

Core: Setting video mode: 640x480
Video: Congratulations, you have 8 auxiliary buffers, we'll use them wisely !

Video: packed pixels extension used

Video: NPOT extension used

Video: use_fbo 0

Video:  --> bias factor 64

Video: num_tmu 2

Video: tbuf_size 2Mb

Core: Initializing 4 RDRAM modules for a total of 8 MB
Core: Starting R4300 emulator: Dynamic Recompiler
Core: Init new dynarec
mupen64plus: ../../src/device/r4300/new_dynarec/new_dynarec.c:8532: new_recompile_block: Assertion `rs1[i+1]!=31&&rs2[i+1]!=31' failed.
Aborted (core dumped)

I added a log line just before the assert:

DebugMessage(M64MSG_INFO, "rs1=%d rs2=%d", rs1[i+1], rs2[i+1]);

and saw that rs1[i+1] equals 31, making it fail

Core: rs1=31 rs2=0

If I understand correctly this is a BEQL instruction, but I don't understand why the operands cannot be 31, is this a special value if there's an overflow?

If I compile without DEBUG=1 it gets a bit further but seems to get stuck in a loop somewhere.

I'm not sure how to debug further, any help would be greatly appreciated.

[Gillou68310]

This is a JAL instruction it makes the program unconditionally jumps with a delay of one instruction. The address of the instruction after the delay slot is placed in the link register r31. The problem here is that the delay slot is using r31 as source register. I don't think that's valid, did you test on real hardware?

[dmrlawson]

I'm not able to test on real hardware, but I'm under the impression that it works. The rom is from here: https://64dd.org/dumps_p.html

[Gillou68310]

Japanese or English version?

[dmrlawson]

I've been trying the English one

[Gillou68310]

ok thanks I'll check

[Gillou68310]

Just for the record here's the disassembly of the recompiled block: 0x80757690.txt

The new dynarec fails to recompile the following because r31 is used as the source register of the JAL delay slot instruction:

• 80757740: JAL 8074ba30 80757744: ADDIU r31,r31,8

[dmrlawson]

So I tested a bit more. If I compile without DEBUG=1 I can run some of the other cartridge ports (Simcity 64 and Mario Artist Paint Studio), but with DEBUG=1 the asserts are checked and it fails with the same error. I'm not sure what's different about F-Zero X but it seems like maybe the JAL instruction is not an issue, but F-Zero X does something else which results in it getting stuck.

What would you suggest trying next?

[Gillou68310]

If the assert is triggered and the game works nevertheless it's just luck trust me ;-)

[dmrlawson]

I'd like to investigate further but I'm not sure where to start. I understand that this ROM works on hardware but I don't have a flash cart to test with. It looks to me like it gets stuck waiting for something but I'm not sure what that could be.

[dmrlawson]

I think this works now