Vib-Ribbon does not advance CD tracks

[JORGETECH]

PCSX-ReARMed Version

r23l c396a64

Your device

New 3DS

Operating System of your device

Other (consoles, etc.)

CPU architecture

ARM 32bit

Issue description

In Vib-Ribbon (European version) the game should play two tracks after selecting a difficulty level, however, when I tested the game in my New Nintendo 3DS the first track plays but the level hangs after the first track, this causes the character to run indefinitely after the first song, making the level unplayable.

I tested the game using CHD and CUE/BIN formats and it happens using both, I haven't tested if the same issue happens in other platforms or using custom CDs inside the game.

Step-by-step reproduction and logs

1. Load the Vib-Ribbon CD in the emulator.
2. Select a language in the game.
3. Select game and "Play with vib-ribbon disc".
4. Select any difficulty.
5. Play the first song without failing, the level hangs after the first round.

[notaz]

I think it works correctly but there was a problem with savestates where using savestates (and derived things like rewind) would corrupt the SPU state. Did you use any of these when you had this issue?

[xjsxjs197]

It should be an issue with the SkipCD region in dfsound/xa.c, This game requires CD data to be placed in spu.spuMem. When executing SkipCD, all zeros are inserted. Comment out the SkipCD (ns_to, decode_pos) on line 87; The code and the game will work fine, but this shouldn't be a good modification

[xjsxjs197]

I don't know if it's appropriate to write it here, but it's also a issue of sound. In the cdrWrite3 method of cdrom.c, The following two sentences are incorrect: cdr.AttenuatorLeftToLeftT = ll; cdr.AttenuatorLeftToRightT = lr; cdr.AttenuatorRightToLeftT = rl; cdr.AttenuatorRightToRightT = rr;

The value of ll--rr should be assigned to cdr.AttenuatorLeftToLeft--cdr.AttenuatorRightToRight. It will result in no XA voice after the start of "hokuto no ken" game.

[notaz]

I didn't realize I broke Vib-Ribbon again. Thanks for the reports, should be fixed now.

[JORGETECH]

I have tested the game again using the latest Retroarch for 3DS nightly (CIA version, as of 7th of December 2023) and I still have the issue, I even went as far as deleting any Retroarch configuration just to be sure it's not related to a bad option but no luck so far. I also disabled a Luma3DS option related to redirecting the app thread but I still see no difference. I should also note I'm not using savestates, I'm starting the game from scratch on every test.

The libretro fork of this repo seems to closely follow the commits from this one and I verified the version I'm using uses the latest commit with the mentioned fixes (c6f4ee7).

[notaz]

Can you post the log, or at least the exact version (serial number) of the game, like SCES02873 or similar?

[saulfabregwiivc]

@notaz the OP says that he was using the European version (PAL) so i am pretty sure the CD-ROM ID is SCES02873.

But i'll leave the Japanese (NTSC-J) CD-ROM IDs too for reference: SCPS45469, SCPS18012, SCPS91213, SCPS91308

[notaz]

I tried SCES02873 on r-pi 32bit with unai + threaded gpu, which is closest configuration I can get to N3DS and it plays both tracks, so there is nothing I can do about this.

[JORGETECH]

I can confirm the CD-ROM ID is SCES02873. Since it's working on a similar architecture I can also agree it's device-specific behavior, although I think it's worth mentioning that N3DS CPU is ARM11 (armv6 without NEON) while Raspberry Pi boards tend to use newer ARM cores, unless @notaz is talking about the original RPi which is ARM11 also.

I'm also thinking the issue could be specific to the libretro port of pcsx_rearmed for the 3DS since that's the port I'm using (the only one available for the 3DS), I will post the issue in the appropriate repo just in case the real problem is libretro's file handling or something similar.

[pcercuei]

@JORGETECH what BIOS do you use?

[notaz]

I've reproduced on pandora (old arm device) and it was timing again, where slight cycle counting differences in ari64 dynarec pushed it out of the window, latest default multiplier adjustment should fix it.

[JORGETECH]

@pcercuei I think I'm using SCPH5501 BIOS, I also have SCPH1001 but I think the newer one overrides it according to libretro's documentation.

I would like to confirm if the timing hack fixed the issue for me but I'm getting a data abort crash when launching any game with PCSX Rearmed using the latest nightly from libretro. This issue is most probably unrelated to non-libretro version since another user reported a similar issue with the Final Burn CPS cores: libretro/RetroArch#16011. I posted a Luma3DS crash dump there.

[notaz]

It's unrelated to that other issue, turns out 3ds mostly doesn't implement sysconf that was needed for non-standard r-pi5 page size thing, so that has broken the ari64 dynarec. Should be fixed now.

[JORGETECH]

The latest fix seems to have solved the issue, now Vib-Ribbon correctly advances tracks. Thanks for all the assistance, I will close the issue.