Feature Request : 64DD support

[7oxicshadow]

I am not sure if this feature request should go here or against RetroArch itself.

Currently neither the RetroArch command line or UI exposes any options for 64DD. I am guessing this is not trivial as if it was it would have been done already.

64DD works quite well in mupen64plus and it is a shame to not be able to use it in RetroArch.

[m4xw]

It's on my TODO, just needs the media loaders hooked up + RA subsystem impl. Look at the dozen branches tho that come first :P

[7oxicshadow]

Good to know its on the the TODO list. Good things come to those who wait :)

[m4xw]

Felt like poc'ing it up:

[7oxicshadow]

Nice. Looking forward to testing when it goes live.

Out of curiosity, will you be exposing commands via the command line to allow 64dd games to be loaded (with the relevant accompanying rom)?

Personally I very rarely use the Retroarch UI in favor of launching games via the command line interface.

[m4xw]

https://cdn.discordapp.com/attachments/555706037412560909/677527269283069991/parallelRSP_al_dd_mupen64plus_next_libretro.7z gliden https://cdn.discordapp.com/attachments/555706037412560909/677501583973548062/mupen64plus_next_libretro.7z IPL goes to system/Mupen64plus/IPL.n64 dd needs to use subsystem loading ndd files via load content isnt supported there

Out of curiosity, will you be exposing commands via the command line to allow 64dd games to be loaded (with the relevant accompanying rom)?

See subsystem

[7oxicshadow]

Thanks for the links. I am a Linux user myself so I was unable to use them but I have instead built your 64dd branch from source.

Couple of things I have noticed:

• If you try to use the subsystem with a cartridge rom file that is in zip format it will just load the base rom and not the 64dd disk.

• Trying to load the 64dd version of f-zero x (with the japan version of of the accompanying rom) starts to load and then hangs on the following screen:

I use the standalone version of mupen64plus with these ndd/n64 combinations and 64dd works fine. I will try to get a log to see if there is anything obvious causing the problems.

[m4xw]

@7oxicshadow for fzero force 1500 vi clock, it will fix it. pretty sure this won't work on standalone anymore, you use a old version of core?

[m4xw]

Also no compression supported for subsystem.

[7oxicshadow]

I have tried setting the VI Refresh (Overclock) option to Auto / 1500 / 2200 and the hang still occurs.

Also to clarify, when I meant standalone I was referring to using mupen64plus as a standalone application (not using retroarch or any cores).

[m4xw]

Yes that's what I am referring too and there it's not functional. wonder if this is a Linux issue I only tested win64. Which of the linked builds did u use?

[m4xw]

Nvm u built it thus gliden/hle

[7oxicshadow]

Just for your own information I have just done a clean build of (standalone) mupen64plus and a clean build of (standalone) gliden64 and 64dd support works great. I am playing it now :)

[m4xw]

Standalone throws a assert because stop after jal, it working is purely luck. I can quote you Gillou on that.

[7oxicshadow]

Weird. I wonder if its a difference between Linux and Windows. I will double check my builds

[m4xw]

Post me your core options?

[7oxicshadow]

I will post the core options in a sec.

The disc version of Mario works with your core but has some odd gfx corruption:

[m4xw]

What the actual fuck

[7oxicshadow]

[m4xw]

Disable n64 depth compare -> its also no longer a default, u might wanna reset all options back to default + set 1500 But I am trying on Switch rn and cant get it to work either there, its unixoid too from the view of the codebase... Gotta look at it tomorrow or so.

[7oxicshadow]

Thanks for working on it. There is no rush obviously. Those of us who do use 64DD will be using alternatives for the time being anyway.

[7oxicshadow]

Just in-case it helps with debugging I think the 64dd version of f-zero x hangs just before the audio is about to play. So audio might be something to consider.

[m4xw]

@7oxicshadow HLE RSP Issue, you need LLE RSP and then force it. I made a new branch (force pushed) rsp-lightning, check that branch out and then git rebase origin/64dd, make sure you did a git remote update prior. That will be gln + parallel rsp.

[m4xw]

Confirmed just now that it works with switch then too.

[7oxicshadow]

Confirmed working on Linux

Mario Disk Version works well aswell. (No corruption)

I made an interesting discovery while testing this. I store and run my games from a NAS storage drive. If I try to run a 64DD disk image from the NAS it will run at about 2 FPS where as if I copy it to a local drive it runs full speed within Retroarch. (Standalone Mupen64plus runs 64DD images from a NAS with no issues)

This discovery isn't a massive issue as I suspect most people run their images from a local drive anyway, but I thought its best to mention it in-case anyone raises a bug in the future...

[m4xw]

I actually use the standalone implementation for the DD Disk image, lol. I just tell it a path

[7oxicshadow]

Ignore me. Further testing has shown that my VI Overclock setting was wrong when testing the NAS configuration.

It seems to work fine now.

[7oxicshadow]

Out of curiosity. When I tried to build your re-based version it would fail at the linker stage saying that it could not find "-lversion".

I think it is a GL library of some sort but could not find what it was on Linux.

In the end i removed it from the makefile and the project still built fine without errors so I am guessing it is something that was carried over from paraLLEl.

[m4xw]

Out of curiosity. When I tried to build your re-based version it would fail at the linker stage saying that it could not find "-lversion".

I think it is a GL library of some sort but could not find what it was on Linux.

In the end i removed it from the makefile and the project still built fine without errors so I am guessing it is something that was carried over from paraLLEl.

eh that is windows stuff, good reminder specifically was required by llvm

[m4xw]

148